Bug Tracker

Opened 7 years ago

Closed 7 years ago

Last modified 5 years ago

#5813 closed bug (wontfix)

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:


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.

Change History (3)

comment:1 Changed 7 years ago by oliverlangan

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);

comment:2 Changed 7 years ago by john

  • Resolution set to wontfix
  • Status changed from new to closed

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.

comment:3 Changed 7 years ago by oliverlangan

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.

Note: See TracTickets for help on using tickets.