423,473 Members | 2,630 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 423,473 IT Pros & Developers. It's quick & easy.

What the heck? The post went through in a reply to this post.

P: 6
I'm testing in Chrome, Edge, FF, IE, and O.

The case is that a page has up to 5 iframes that show on a single page. A page is executed in each iframe. These pages have links to other pages that have links. A browser refresh returns the screen to the initial page state in all 5 browsers. But in Chrome and O, the history of the iframes of the set are not deleted. The browser back button or a JavaScript history(-1) button work as originally intended in FF, IE, and Edge. But in Chrome and O, these back buttons start to step back through the sequential history of all iframes. And the same thing happens with a single frame.

I do a querySelectorAll('iframe') on exit and refresh/load and no iframes are indicated. Yet, in Chrome and Opera, when the page refreshes and the iframes are created again, they remember the history of the same named iframes that were there before the refresh.

I refresh in 3 different ways in this application including the browser refresh button, parent,location,reload(parent.location.href), and parent,location,reload with a particular function. These all work in Edge, FF, and IE. I refresh and can back out of the page to the calling page. In chrome and Opera, even though the iframes have been removed, the new iframes retain the history of the previous iframes.

I have tried about half dozen approaches in JavaScript to insuring the iframes have been removed. My latest attempt follows. I'm not sure if I'm executing right, but the length is always 0.

Expand|Select|Wrap|Line Numbers
  1. var iframesx = document.querySelectorAll('iframe');
  2. for (var i = 0; i < iframesx.length; i++) {
  3.  iframesx.parentNode.removeChild(iframesx);
  4. }
  5.  
This is a real navigation problem for this application in Chrome and Opera, and I would think for any application in a similar situation. The browser Back button and JavaScript History() methods are fundamental page navigation tools. Below is a link that demonstrates the problem. The page shows up to the 5 most recent years of a color map. All data is only for testing and some of the data was doubled up for testing. I believe this is a Chrome and Opera error. I've tried to find a way to clean up iframe history thouroghly, but with no success.

http://steepusa.no-ip.info/scx/gencm...ildren2%2Eview

Bring the page up in Chrome or Opera. Take some links in a couple of iframes. Refresh and hit the browser Back button as if you are backing out of the page. In Edge, FF, and IE, instead of going through the history of the iframes before the refresh, the back out works.

My platform is Windows 10 running Apache/2.0.64 (Win32), mod_perl/2.0.3, and Perl/v5.8.3. I am running the latest versions of all browsers being used in testing. However, I think this problem exists independent of platform.

Any help will be appreciated, including why this post was flag. Thanks.
Aug 9 '18 #1
Share this Question
Share on Google+
8 Replies


gits
Expert Mod 5K+
P: 5,175
well - such happens when using iframes or frames - which is a kind of uncommon thing in the days of single page applications. i never came across such an issue - so i am just trying to 'guess' here after a quick lookup of similar and some older issues - in an attempt to help finding a workaround:

Do your iframes have names? can you name them dynamically so that in case of a reload the iframes always have unique names(add a timestamp or such)?
Aug 10 '18 #2

P: 6
Good suggestion. I'll try it. This app has been developed over about 9 years at this point. This was dome in frames and it worked well in all 5 browsers. I reworked this into iframes in going toward the HTML5 standard. And this came up. Maybe object would be a better choice. I'll be back. Thanks.
Aug 10 '18 #3

P: 6
The random naming (name and ID) did not work. The result was pretty much the same. How can the new iframes (new NAMEs and IDs) created after the refresh be associated with the history of the iframes that existed before the refresh.

I'm kind of at a loss. I need a cross browser solution. Maybe the html5 'object' would be a better choice than the iframe. Any suggestions would be appreciated.
Aug 10 '18 #4

P: 6
The following code did seem to modify the Chrome and Opera behavior.

Expand|Select|Wrap|Line Numbers
  1. window.addEventListener('beforeunload', function(event) {
  2.  
  3.     var iframesx = document.querySelectorAll('iframe');      
  4.     for (var i = 0; i < iframesx.length; i++) {      
  5.       iframesx[i].history.back(iframesx[i].history.length); 
  6.       iframesx[i].parentNode.removeChild(iframesx[i]);      
  7.     } 
  8.  
  9.   //}  
  10.   }, false);
First, I'm assuming its getting executed in these 2 browsers because I can't seem to get an indication by returning a string, but the behavior did change.

Now, after the refresh, when I hit the Back button, it does not step through the sequential history of the iframes. The visual history seems to be gone.

But the Back button has to be entered the same number of times as the combined history entries in the iframes to actually leave the page containing the iframes, even though the iframes no longer step sequentially through that combined iframe history visually on the screen as the Back button is entered.

As you can see from the new line of code, I tried to clear the Back history before removing the iframes, but it did not seem to work.

Again, any help is appreciated.
Aug 10 '18 #5

gits
Expert Mod 5K+
P: 5,175
hmmm - may be you can have a look here - and see if that would work somehow:

http://www.webdeveasy.com/back-butto...ith-an-iframe/

it uses the history.replaceState method. Read the comments below the article there as well first - it assumes though that you have control of the pages in the iframes - else its all x-domain and wont work.
Aug 13 '18 #6

P: 6
Thanks gits. I'll try this. And I appreciate your help. Do you think this has to be run in every link that can happen in an iframe? I'm thinking so, but can not really tell from the article. It looks like the code is embedded inline at the bottom of any reachable page in the iframe.

I do want to ask another question. My original direction in the application I'm working on was a cross browser solution. I'm at the completion of my system test set and everything has tested as intended up to this iframe navigation problem in all 5 browsers and Safari (not really in browser test set). I've tried several JavaScript things and some design adjustments, like the randomly iframe IDs and NAMEs, with no success. I'm going to try this suggestions. The domains of all links in the iframe are my server domain. I'm hopeful on this. This looks good. I'm excited.

But if it doesn't work, even though I'm sure I'll keep trying, I'm thinking I've run into an area where the standards work in Chrome, FF, and Opera is not quite finished.

Edge and IE are the only 2 browsers I'm testing in where this behavior is as expected. It does not make any sense to me to step back through the iframes combined histories when hitting the browser Back button after a browser Refresh. Refresh to an initial page state should include all page state aspects.
What do you think on this gits?

And I would really like to know how new iframes with random NAMEs and IDs, created after a page Refresh, retained their association with the history of the iframes, with random NAMEs and IDs, before the Refresh?

If this problem holds up, I can redesign or let go of the cross browser hope. I like the facilities that this navigation problem has occurred in (4) and would like them to work as is. But I would like to achieve the cross browser intention also. I'll get on this right away. Thanks gits.
Aug 13 '18 #7

gits
Expert Mod 5K+
P: 5,175
well - as far as i see it - when all pages in the iframes - even the links that are to be followed - then you can manipulate everything centrally from the parent for example - if there is a page from another domain - the browser will not allow that due to the same origin policy. may be you can use the frame's onload event to run through the links and inject the replaceState method if that works at all.

tbh - i am not feeling like being that helpful this time - since i cant really help with a solution at them moment due to a lack of time for such - i can only give hints how i would probably approach it in such a situation.
Aug 13 '18 #8

P: 6
I have not be able to get the replaceState to work. This seems like the same case, but I have not been able to modify the behavior in question in Chrome, FF, and Opera.

Thanks gits for your help.

The application tests right completely only in Edge and IE now. Chrome, FF, Opera, and Safari fail the same way, although somewhat variably. I'll keep trying the replacestate, anything else I can find that might work, and consider redesign. Until then, the application runs correctly, as designed, only in Edge and IE.
Aug 14 '18 #9

Post your reply

Sign in to post your reply or Sign up for a free account.