Skip to main content

Bug Tracker

Side navigation

#5813 closed bug (wontfix)

Opened January 15, 2010 06:13AM UTC

Closed January 22, 2010 10:07PM UTC

Last modified March 15, 2012 10:26AM UTC

Safari: jQuery 1.4.0 fails to fire the ready() event when navigating to pages via History stack

Reported by: oliverlangan Owned by: brandon
Priority: major Milestone: 1.4.1
Component: event Version: 1.4
Keywords: safari history ready Cc:
Blocked by: Blocking:
Description

In jQuery 1.4.0 release, Safari no longer fires the $(document).ready() event when navigating to a page via the history buttons (back or forward).

This is a change from version 1.3.x, which correctly fires the event.

Adding any unload event handler to the page will fix the problem (see http://stackoverflow.com/questions/158319/cross-browser-onload-event-and-the-back-button ); so I suspect this bug was introduced by preventing the "Prevent memory leaks in IE" code from running on other browsers.

Attachments (2)
Change History (3)

Changed January 15, 2010 06:38AM UTC by oliverlangan comment:1

Does not happen on Firefox/Mac or Chrome/Mac.

Re-enabling the window unload code on Safari fixes the problem, but possibly with some performance cost. A simple solution is to bind a noop to unload on Safari:

jQuery(window).bind("unload", jQuery.noop);

Changed January 22, 2010 10:07PM UTC by john comment:2

resolution: → wontfix
status: newclosed

This is very much intentional - attaching an unload will force the page to not be cached by the browser and it'll be reloaded (which is not good). This was actually a very beneficial change in 1.4. If you wish to have the ready even re-run then you should probably just attach the unload handler yourself.

Changed January 24, 2010 08:22AM UTC by oliverlangan comment:3

Ah, I see I have improperly blamed jQuery for a different problem I am seeing: Safari is not re-establishing setInterval functions when the page is restored via the history buttons.

I can't find a bug to that effect on the WebKit tracker, but I can see from some testing that the issue is fixed in the WebKit nightlies.