Browser back button behavior before and after refresh

ct8638 · October 26, 2018, 12:42pm

I’m testing an application in Chrome, Edge, FF, IE, O, and Safari. A particular page generates up to 5 iframes loading up to the 5 most recent color maps of a measure in each. Each color map has many image map links. Consider the following browser Back button behaviors before and after a browser Refresh, after I take some links in any of the iframes.

browser Back button behavior before Refresh - the links taken in all iframes are combined into the history of the page the iframes are embedded in. Each Back button results in all 6 browsers stepping back through that combined history in a ‘last link taken first’ order, which is what I would expect.
browser Refresh resets the page and all embedded iframes to their entry state in all 6 browsers, which is what I would expect.
browser Back button behavior after Refresh - In Edge and IE, the next Back button after the Refresh exits the UI, which is what I expect. However, in Chrome, FF, O, and Safari, the next Back button(s) after the Refresh step back through the combined history of the previous session of the page BEFORE the Refresh. I reproduced the same behavior with object elements instead of iframes. I’ve even generated random iframe NAMES and IDs with the same result.

Can anyone help me understand this. That after a Refresh, the page steps back through the combined history of the previous session before the Refresh makes no sense to me. A page Refresh that returns page elements to the entry state should delete the history of those elements I think. I have considered replace state in JavaScript, but I’m not seeing it very clearly. If onLoad, I prevent iframes links from adding to page history, then I cannot step back through history prior to a Refresh, because none of the links taken would have been added to history I think.

Here is a link to show the behavior in question loading off my home Apache server. I hope this does not get flagged as spam. It is a good demonstration of what I’m talking about in this post. This work is taking place on my Apache home server. It shows 6 iframes, 5 of which are the latest 5 years of test color maps for a measure in Kentucky counties.

http://steepusa.no-ip.info/scx/gencm1m.cgi?str=0~SKY~C%253A%252FSteep%252FUSA%2520Data%252FState%252FKY%252F~C%3A%2FSteep%2FUSA%20Data%2FState%2FKY%2Fhealthybirths.view~l

Copy the link and try it in Edge or IE and Chrome, FF, O, or Safari. Take some of the links in each iframe containing a geographical year. Then do the 3 steps above.

Which approach to handling page history after a refresh do you think is correct? I think the Edge/IE approach is. As UI designers, what do you think? Any opinions or help will be appreciated.

Thanks. craigt

Mittineague · October 26, 2018, 7:16pm

AFAIK, both are correct

https://www.w3.org/TR/2011/WD-html5-20110113/history.html#the-session-history-of-browsing-contexts

User agents may discard the Document objects of entries other than the current entry that are not referenced from any script, reloading the pages afresh when the user or script navigates back to such pages. This specification does not specify when user agents should discard Document objects and when they should cache them.

It’s been quite a while since I’ve worked with “back” and I don’t remember the specifics, but IIRC, some browsers did “reload from cache” and others did “load anew”. At the time the “solution” was for me to learn how to use my browsers to have pages load as I wanted them to.

Not ideal to depend on visitors needing to learn how to use their browser and I never investigated on how to use code to “standardize” the behavior. Sorry I’m not more help, but that’s all I’ve got.

ct8638 · October 27, 2018, 5:12pm

Thanks for your response Mittineague… Among the things I had tried are the HTML 4 meta tags below in the header of the program that generates the page with the up to 6 iframes.

 <meta http-equiv='Cache-Control' content='no-cache, no-store, must-revalidate' />
 <meta http-equiv='Pragma' content='no-cache' />
 <meta http-equiv='Expires' content='0' />

They work for FF, but have been deprecated in HTML 5.

The JavaScript location.reload(true) is supposed to be cross browser and force a reload from disk, but I don’t know what it does to page history. I added a Refresh button to the 1st iframe (top left most) the did a parent.location.reload(true), but it did not clean up page history for the 4 browsers in question.

I have not been able to find a cross browser solution that cleans up page history on a browser Refresh. Its probably me. I’m still hoping. The location.reload() may be the answer and I’m just not implementing it correctly.

I do want to add that if page history is not cleaned up in some standard way after a browser refresh and there is not a way to programmatically clean up page history after a refresh, in some cases navigation will be really awkward. I did find the code below, but am not sure how to use it.

caches.open('v1').then(function(cache) {
  cache.keys().then(function(keys) {
    keys.forEach(function(request, index, array) {
      cache.delete(request);
    });
  });
})

I think it is using a list of cache element keys to delete the elements of cache. But Its not to clear to me when I should run it or really how to know it ran OK.

TechnoBear · October 27, 2018, 5:15pm

Off Topic:

@ct8638: when you post code on the forums, you need to format it so it will display correctly.

You can highlight your code, then use the </> button in the editor window, or you can place three backticks ``` (top left key on US/UK keyboards) on a line above your code, and three on a line below your code. I find this approach easier, but unfortunately some European and other keyboards don’t have that character.

ct8638 · October 28, 2018, 3:22pm

I want to restate step 3 in the original post. My first statement was not quite right.

browser Back button behavior after Refresh - In Edge and IE, the next Back button after the Refresh exits the UI, which is what I expect. However, in Chrome, FF, O, and Safari, the next Back button(s) after the Refresh refreshes the page the same number of times as the number of combined history entries BEFORE the Refresh and THEN leaves the page. The iframe content is not actually changing because step 2 reset the page to its initial state. The page just refreshes with each Back button entry until the number of Back button entries equals the number of combined page history entries. The next Back button then leaves the page. I reproduced the same behavior with object elements instead of iframes. I’ve even generated random iframe NAMES and IDs with the same result.

In Chrome, I open the link in the original post. I take some links in the iframes. Then I enter PF12 to bring up the Developers Tools and right click on Refresh causing Chrome to give me a drop down with an erase cache and do a hard refresh choice which I take, The same thing happens as described above. The page returns to its beginning state and I have to hit the back button the same number of times +1 as the number of links I took before I took the erase cache and hard refresh choice.

This test makes me think that erasing cache and reloading from the server (hard refresh) are not the answer. I’m sort of confused on this. The page thinks it has history after the Refresh. But when I hit Back, the page simply does a refresh until the number of Back entries equal the number of links taken before the Refresh. The next Back leaves the page, which is what I think should happen right after a Refresh, from a navigation point of view.

Mittineague · October 28, 2018, 6:29pm

I would be looking for a different approach if possible. I guess you could figure out the different ways various browsers implement the iframe history object, write code to deal with each, and keep up with changes as they occur. But that would be a major task to put together and maintain (i.e. you will be forever bug squashing).

https://www.w3.org/TR/2011/WD-html5-20110113/history.html#history-notes

5.4.4 Implementation notes for session history

This section is non-normative.
… … …
Similarly, a page containing two iframe s has a history object distinct from the iframe s’ history objects, despite the fact that typical Web browsers present the user with just one “Back” button, with a session history that interleaves the navigation of the two inner frames and the outer page.

* note the “non-normative”

ct8638 · October 28, 2018, 8:08pm

Mittineague, 1st I want to say thanks for your thoughts. I’ve posted this in 3 forums and over 300 people have looked and your the only 1 who offered an opinion.

Did you look at the UI? If not, would you please load the link into Chrome, take 3 links in any of the iframes, refresh the UI, and hit the Back button 3 times. It just refreshes the screen. This makes no sense. Its like it thinks there is history, but there is not.

I think I understand from what you said that the specification is ambiguous.concerning the discard of the history object. And I think I understand that a page with 2 iframes has a history object that is distinct from the history object of each iframe.

These UIs in question, like the one shown in the link, work just as designed and expected in Edge, IE, and now FF for the time being with HTML 4 meta statements that I guess are still supported in FF. The way Chrome and Opera work after taking iframe links and refreshing makes no sense to me and makes navigation very awkward.

No new approaches are coming to mind. These UIs work just the way I wanted them to work and thought they would. And this seems like a bug where the clean up of the combined page history was not completed in the browsers in question.

Could you please comment on what you see in the link after doing the scenario I outlined. This can’t be right in any sense I’m thinking. When a user digresses into the links of the iframes on the page, they simply hit refresh and back to leave. The way it works would have users complaining. They would not want to have to hit Back for every iframe link taken in all page iframes before the refresh. Maybe what your saying is that I’m stuck because this is the way it works in the browsers in question.

I sure don’t want to figure out the different ways various browsers implement the iframe history object, write code to deal with each, and keep up with changes as they occur.

Again thanks for your time.
craigt

system · January 28, 2019, 3:08am

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.