So I'm creating some HTML using javascript based on where the user clicks on the page. On page load the script replaces an empty div with a ul and some data. The user clicks on that data to receive more and so on. Now when the user navigates off the page and then hits the back button to go back to the page, IE displays a blank page with the replaced divs, in all other browsers, FF, Opera, Safari, the page either reloads to the initial ul or goes back to the last state with the dynamic data in it.
Anyone have an idea as to what might be happening here? Any help is appreciated.
It sounds like you need to manage the history and state of your page. Check our Brad Neuberg's Really Simple History.
The behaviour of onload events when navigating backwards and forwards is not standard cross browser. As a general rule, I have found that when you click back, onload events tend not to work as the browser is loading it from cache rather than re-requesting the page. What you can try is using the dom ready event rather than window load.
Trull's answer is along the right lines. Opera and later Firefox(>1.5) do not consider loading a page from the cache as requiring to trigger an onload event as the complete DOM state is also cached.
This is trivial to standardise across browsers, as Opera and Firefox do not exhibit this behaviour if you define a window.onunload event. See http://developer.mozilla.org/en/Using_Firefox_1.5_caching
Related
From mozilla docs:
A popstate event is dispatched to the window every time the active
history entry changes between two history entries for the SAME
DOCUMENT.
Which window event should i use if i need to listen to 'session history changes' ACROSS DOCUMENTS in a browsing context?
I am writing a js library that helps tracking navigation when user use back/forward browser buttons. The library would record when user is navigated from page B to page A (backwards) or page A to page B(forward). I've achieved the tracking for the pages that use hashes using the 'popstate' event but when user navigate from page A to page B this event doesn't work.
I've looked at pageshow/pagehide events but they fires on simple page loads as well and not just when the 'session history' changes (ie page fetched from history).
What should i be looking at to know "browser has looked into session history to fetch the current page"?
You're going to have to handle the Window's beforeunload event, and also put code on whichever page loading event is appropriate for your use case.
Note that for beforeunload, you don't have time to write something server-side. You'll have to track this in LocalStorage.
There is something weird in your requirements:
You say you are writing a js library, but for this library to work across different documents, for a start, it would at least have to be executed on every documents navigated by the user.
And even if it were the case, there wouldn't be any solid way to do what you want.
Browsers' behavior regarding history navigation vary a lot:
For instance, FF will keep in memory its current state, and will not reload the page per se, but simply reactivate its saved state (i.e you won't even be able to know that the user came back to this page (apart from ugly polling of performance.navigation.type, which despite what MDN says is only absent in Safari).
So all in all, what you want to make is a job for a browser extension, not for a web-library.
I have a script that writes an iFrame which loads a page. I created a JSFiddle to make things clear:
link JSFiddle loading CNN in a frame
This loads CNN in a frame. If you scroll down in the frame to the news and click on the new articles and then 'back' there is some strange behavior in both Safari and Google Chrome: clicking 'back' doesn't take the iframe 'back', it takes the entire parent frame 'back'. How can I prevent this from happening?
Also strange is that fact that this doesn't always happen. Try it out for yourself, click at least 5-10 links and you'll see that the fiddle will reset itself every now and then. And that shouldn't happen...
This is behavior that only seems to happen in Safari en Chrome, Opera and IE don't seem to have this problem...
Browser registers history events when you click different URLS, since iframe is part of the page u are on it will register the click inside the iframe as a history event of the parent page. Different browsers may have slightly diferent behavior - I expect FF and Chrome be one way and IE behave slightly different. However testing your example both Chrome and IE worked exactly the same and pretty much as expected.
So to clarify:
Loading JSFiddle is a historical event as far as browser is concerned.
Clicking the button to create and load an Iframe is NOT a historical event.
Clicking a URL link within the Iframe window is a historical event.
At this point u have 2 states that the browser remembers and you can go back and forth in history between them.
closing window
refreshing page
clicking on a link
??
It seems to be inconsistent. (I'm shocked!) Is there a list somewhere? I'm particularly interested in Firefox, but am curious about others, as well. The Mozilla docs are vague:
window.onbeforeunload
An event that fires before the unload event when the page is unloaded.
window.onunload
The unload event is raised when the document is unloaded.
Gee, thanks.
window.onbeforeunload will trigger before you navigate to away from current page (from URL address, BACK button, close browser, etc.)
The event will not fire in Opera. But all the other browsers seem to respect it OK.
I have used this in the past for AJAX-intensive sites, mostly as a way to avoid having to support the BACK button.
It also works well as a confirmation dialog to prevent you from accidentally losing your work. But users might get annoyed by the confirmation. So this might not be a good enough reason to use it.
This already works well in FireFox, IE and Opera, but in Chrome and Safari this is a problem. I have an onClick event function on links that leaves the page. These functions send requests to various tracking services to record the exit link.
I have tested this by removing the href attribute in the link. When it's removed, the link is tracked. When the link is active (and leads away from the page) the link is not tracked. This is only the case in Chrome and Safari.
I was hoping there was some non-extreme way of forcing the browser to finish the script before leaving the page. (By extreme I mean f.inst. removing the href attribute using javascript and manually redirecting the browser after tracking is complete)
jQuery is already loaded in this project, so it'd be great if it had a solution.
Thanks for any and all advice
Google analytics _trackPageView does not offer a callback so you have no easy way to get a success callback, then proceed to your next page. There is a callback though on _trackEvent, and that's triggered each time some GA event occurs. You can try this and listen for it like so (make sure to put your href's back into your links - this depends on that being there, plus you'll get graceful degradation):
$(".myLinkClass").click(function(e){
e.preventDefault();
var link = $(this).attr('href');
pageTracker._trackPageview('/outbound/'+link);
if (pageTracker._trackEvent("Outbound", "URL", link)) {
window.location = link;
}
});
There may be different reasons of page unloading:
1 User closes the current window.
2 User navigates to another location.
3 Clicks the Back, Forward, Refresh, or Home button.
4 User submits a form, and then browser starts to unload current page and load page with results of form submitting. (Assuming that the current window is the form's target).
5 and so on...
Can I somehow know in onunload handler that the reason of unloading is p.4, i.e. moving to page with results of form submitting?
I could define some flag when submiting form, but this does not solve the problem. Because response (on form submit) from web server takes some time, browser doesn't unload the current page immediately and waits response from server. And during this waiting user may close window or navigate anywhere. And I need to know whether was it indeed moving to results page or something else...?
You could hijack some of those events.
For example for links, you could add an event handler on links that saves their href attribute, performs what you require, then sets window.location to the href you had stored in a variable.
The exact reason of page unload cannot be known in the unload handler. OnUnload event is not a standard and was implemented by IE first.
Different browsers might handle it differently and fire the event for different cases.
msdn reference
mozilla reference
So if you are trying to know the reason of unload in the unload handler, I think you might be out of luck. However as Alex pointed out in his answer, you could probably know about user navigating away from your page by clicking some link on your page by making your click handlers for those links more intelligent.
on unload cant handle its looks like but maybe when load you can handle.
as explained
performance.getEntriesByType("navigation")[0].type
You can check this Link
What is the replacement for performance.navigation.type in angular?