While testing browser behavior regarding inline JavaScript evaluation and the back and forward buttons I found a very interesting thing. When a script is included in the HTML to execute on parsing (not on load but inline) Internet Explorer (7 on Vista tested) and Safari 3 for Windows will re-execute the script when a user returns via the back button. In my mind this is the correct behavior, since you actually visited the page twice.
The thing is that Firefox (2.0.0.6 on Vista tested) and Opera (9.20 on Vista tested) don’t agree with me. Well maybe they do and don’t live by their beliefs. What they do is nothing. You come back and no scripts are executed. Not even one request is sent to the server in Firefox.
This “feature” is sometimes a great thing – all the AJAXy stuff and all the JavaScript enhancements are already there and don’t need to be rendered again in turn saving power and time. At other times it’s a pain in the a** since some stuff does return to its default state and some doesn’t. This problem is most often observed with dynamic/advance forms that lose their default values/states. Since even onload is not fired this can get annoying…
Besides all the interface problems you might encounter due to this “rogue” behavior, there are also a few issues regarding statistics. It’s harder to inspect the path of a user, the time a user spent on a page, the number of page views in a visit and other related metrics. The other significant issue is that browser usage statistics might be skewed. To answer this last issue we’d have to know how these statistics are measured.
Let’s take a user that is used to clicking the back button while navigating a site with a 2 level deep navigational tree. She comes to the page, goes in one branch and then to a second, very distant branch. Internet Explorer would register 7 page views (1 on the root, 2 to get down, 2 back up and 2 more down), while Firefox would only register 5 page views (1 on the root, 2 to get down, ignore the 2 back buttons, 2 more down) – a 1.4:1 ratio.
If the statistics are based on sessions or unique users we have 50% IE and 50% FF. If we base them on hits we have 58% IE and 42% FF – a 16 percentage point difference or as we said before a 40% difference. This is not something you could just ignore…
Exercise for the reader – why do “unsupported” browsers always have a small browser share in hit based browser metrics?
I’m looking into the effect on the analytics stats that the No Script Firefox add-on…
I think that as many as 5% of Firefox users might be using it which will push the underrated figure even higher.
Please, let me know if you have any further data…
Many thanks.
This used to be one of Opera’s most important features, now copied in Firefox: to speed up back/forward navigation AND avoid loss of user input data, we cache the *generated* DOM, not what the server sent. So the complete, generated DOM is what you usually return to when using the back button. This is much faster than re-initializing the page and has the important benefit that it’s trivial to keep form state the same so that what you have typed into a TEXTAREA or INPUT is not lost if you accidentally go back and forward.
This feature *requires* not sending onload on back/forward navigation. The reason is that onload is often used to create parts of the page, for example a DHTML menu. Imagine if each time you went back and forward Opera cached the current DOM structure, and sent onload to a script that added another copy of the DHTML menu! It would end up with a complete mess.. Hence no onload. Firefox has implemented pageShow and pageHide events which I wish Opera will copy eventually.
Finally, the rapid history navigation caused problems with for example buttons disabled by script when you click them to send a form remaining disabled. Opera now implements some heuristics to sometimes re-initialise pages – see this link for more information:
http://www.opera.com/support/search/view/827/
Your point about statistics is really thought-provoking – thanks!