jQuery: The Write Less, Do More JavaScript Library

Ticket #1319 (closed bug: fixed)

Opened 1 year ago

Last modified 8 months ago

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

Reported by: dmethvin Assigned to: anonymous
Type: bug Priority: major
Milestone: 1.2.2 Component: event
Version: 1.2 Keywords:
Cc: Needs: Review

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

jquery_test.html (3.5 kB) - added by davidserduke 8 months ago.
test case (slightly modified so can download)
safariready_test.html (0.9 kB) - added by davidserduke 8 months ago.
simplified test case 2
slowcss.php (152 bytes) - added by davidserduke 8 months ago.
simplified test case 2 data
1319.diff (1.5 kB) - added by davidserduke 8 months ago.
patch
1319plus.diff (2.3 kB) - added by davidserduke 8 months ago.
patch plus opera change

Change History

  Changed 1 year ago by john

  • version changed from 1.1.2 to 1.1.3
  • component changed from ajax to event
  • milestone changed from 1.1.3 to 1.1.4

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

  Changed 1 year ago by akuzemchak

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 1 year ago by shameister

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

  Changed 11 months ago by john

  • status changed from new to closed
  • version changed from 1.1.3 to 1.2
  • resolution set to worksforme
  • milestone changed from 1.1.4 to 1.2.1

Unable to duplicate.

  Changed 9 months ago by edd

  • status changed from closed to reopened
  • resolution deleted

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 9 months ago by edd

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 9 months ago by brandon

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

Changed 8 months ago by davidserduke

test case (slightly modified so can download)

follow-up: ↓ 9   Changed 8 months ago by davidserduke

  • milestone changed from 1.2.1 to 1.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.

in reply to: ↑ 8   Changed 8 months ago by davidserduke

Let me try those two lines again:

//window.onload = (function () {

$().ready(function () {

follow-up: ↓ 11   Changed 8 months ago by brandon

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.

in reply to: ↑ 10   Changed 8 months ago by brandon

Replying to 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 8 months ago by davidserduke

simplified test case 2

Changed 8 months ago by davidserduke

simplified test case 2 data

  Changed 8 months ago by davidserduke

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 8 months ago by davidserduke

patch

Changed 8 months ago by davidserduke

patch plus opera change

  Changed 8 months ago by davidserduke

  • status changed from reopened to closed
  • resolution set to fixed

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.

Note: See TracTickets for help on using tickets.