Skip to main content

Bug Tracker

Side navigation

#1319 closed bug (fixed)

Opened June 25, 2007 01:34PM UTC

Closed December 04, 2009 08:28PM UTC

Last modified March 14, 2012 04:47AM UTC

$().ready() sometimes fires too soon on Safari/Win

Reported by: dmethvin Owned by:
Priority: major Milestone: 1.4
Component: event Version: 1.3.2
Keywords: Cc:
Blocked by: Blocking:
Description

(It may also fire too soon on Safari/Mac but I can't test that.)

Go to this page in Safari/Win:

http://methvin.com/jquery/splitter/vsplitter.html

Occasionally, it will not initialize properly--the right pane is too short by the width of a non-existent scroll bar. You may need to reload it repeatedly to see the problem.

I think this is due to one or more document properties being invalid at that point. If I remove the special-case Safari handling in jQuery's ready() method and let it drop into the onload case instead, the problem goes away.

According to this page, Safari fires onload *very* early, before the page has displayed, so that code is most likely overkill anyway.

http://www.howtocreate.co.uk/safaribenchmarks.html

Attachments (6)
  • 1319.diff (1.5 KB) - added by davidserduke December 19, 2007 08:54PM UTC.

    patch

  • 1319plus.diff (2.3 KB) - added by davidserduke December 19, 2007 11:24PM UTC.

    patch plus opera change

  • jquery-example.htm (0.8 KB) - added by darkangel June 10, 2009 05:23PM UTC.
  • jquery_test.html (3.5 KB) - added by davidserduke December 16, 2007 11:29AM UTC.

    test case (slightly modified so can download)

  • safariready_test.html (0.9 KB) - added by davidserduke December 17, 2007 11:31PM UTC.

    simplified test case 2

  • slowcss.php (0.1 KB) - added by davidserduke December 17, 2007 11:31PM UTC.

    simplified test case 2 data

Change History (20)

Changed July 20, 2007 12:53PM UTC by john comment:1

component: ajaxevent
milestone: 1.1.31.1.4
version: 1.1.21.1.3

I have not been able to duplicate this, even with your test page. Are you still able to duplicate it?

Changed August 10, 2007 04:35PM UTC by akuzemchak comment:2

I've noticed the same thing happening on my site:

http://thoughts.kuzemchak.net/

The archives area (under the main nav) should hide by default using $(function() {...}), but in Safari 3 it will still show unless the page is refreshed.

Changed August 25, 2007 12:06AM UTC by shameister comment:3

Happened at http://methvin.com/jquery/splitter/vsplitter.html in only one of nearly 50 calls, but really appears.

Changed September 15, 2007 01:18PM UTC by john comment:4

milestone: 1.1.41.2.1
resolution: → worksforme
status: newclosed
version: 1.1.31.2

Unable to duplicate.

Changed November 16, 2007 11:28AM UTC by edd comment:5

resolution: worksforme
status: closedreopened

I can make this happen almost every time at http://methvin.com/jquery/splitter/vsplitter.html -- Safari 3.0.4, Mac OS 10.5

I also have the problem where hide() doesn't work in a $(document).ready() context. I must use css({display: 'none'}) instead.

Changed November 16, 2007 11:57AM UTC by edd comment:6

So, a workaround is to use $(window).bind("load", ...) instead of $(document).ready() on Safari.

I've still not figured out why this bug happens on some pages but not on others, alas.

Changed November 16, 2007 08:37PM UTC by brandon comment:7

Can you verify this bug still exists with the latest SVN?

Changed December 16, 2007 11:31AM UTC by davidserduke comment:8

milestone: 1.2.11.2.2

It seems to still happen in the current SVN. I modified the test case so you can download it. By editing the jquery_test.html file you can see there are two lines that are:

//window.onload = (function () {

$().ready(function ()

By commenting one and and one in, the problem shows itself.

Changed December 16, 2007 11:32AM UTC by davidserduke comment:9

Let me try those two lines again:

//window.onload = (function () {

$().ready(function () {

Changed December 16, 2007 09:44PM UTC by brandon comment:10

I can also confirm this happens in Safari 3 win. However, I don't think we can rely on the window.onload event to always act as it currently does in Safari 3. The article you link to specifies that this "bug" is marked fixed in their bug tracker. Not sure what fixed means but I imagine it isn't want we want. The webkit nightlies support the DOMContentLoaded event but until then we will need to figure out anther hack for Safari.

Changed December 16, 2007 09:44PM UTC by brandon comment:11

Replying to [comment:10 brandon]:

I can also confirm this happens in Safari 3 win.

I meant to say: I can also confirm this happens in the latest Safari 3 win and mac.

Changed December 17, 2007 11:35PM UTC by davidserduke comment:12

I'm not positive yet, this appears to be a problem with an external css file not being loaded and applied before the ready event fires. I'm guessing that is what causes this racing condition where it sometimes works and sometimes doesn't.

So I put together a simplified test case using php instead of a css file and a 1 second pause when loading it. There is a problem where the width is returning 'auto' at the ready event then '100px' at the onload event. I suspect this might be the problem. Opera is returning '0' at the ready event (but it works in the initial test case). FF and IE both return '100px' for both events.

Changed December 20, 2007 06:05AM UTC by davidserduke comment:13

resolution: → fixed
status: reopenedclosed

Fixed in [4245]. There are many possible scenarios and edge cases to this kind of bug. The current fix seems fairly solid but until it gets tested in the beta we can't be sure. Please reopen the bug (if) with any problems you see ASAP.

Changed January 09, 2009 08:35PM UTC by britter comment:14

resolution: fixed
status: closedreopened

I am now noticing this problem again. Safari v3.2.1 windows. Issue is that Ready event fires before css files have loaded in safari. Simple / Easy work around is to declare your css files in the document head BEFORE the script files. If CSS files are after script files then the event fires before the css has loaded.

Changed January 17, 2009 06:50PM UTC by dmethvin comment:15

I've updated the entry for .ready() to emphasize that css needs to all be loaded before script, especially on Safari.

http://docs.jquery.com/Events/ready

Changed January 28, 2009 03:29PM UTC by DG55 comment:16

I can confirm this is a problem in Safari 3 for Mac, and Google Chrome (essentially all new Webkit based browsers).

Putting the CSS above the scripts does work, but it seems strange this hasn't been fixed yet - or is this a Webkit bug?

It seems fairly obvious that the whole point of the ready function is to start things at the point that all the essentials have loaded, so (if possible) a fix should be in order.

Changed June 10, 2009 05:34PM UTC by darkangel comment:17

I don't think this has anything to do with CSS. I've attached a very simple example that shows that setting designMode inside jQuery's ready() function fails in Safari Win 4.0 (530.17) and Chrome 2.0.172.30.

Changed December 04, 2009 08:28PM UTC by john comment:18

milestone: 1.2.21.4
resolution: → fixed
status: reopenedclosed
version: 1.21.3.2

An additional check was added to 1.4 to make sure that the body is available, at least, before the ready event will fire. This should resolve the issue.

Changed April 05, 2011 04:16PM UTC by vitaliypodoba@gmail.com comment:19

I'm getting similar issue in Safari with images. Shouldn't ready() be called after browser fetched images on a page? At least It works fine in other browsers. But in Safari it only works on full page reload (Shift+Reload).

Changed April 05, 2011 04:18PM UTC by ajpiano comment:20

No, ready is NOT fired after the browser downloads images on a page, ready is fired when the dom is manipulable but before the images have downloaded.