Bug Tracker

Modify

Ticket #7273 (closed bug: wontfix)

Opened 3 years ago

Last modified 2 years ago

Ready event fired multiple times if an unhandled exception occurs

Reported by: Michael Warning Owned by:
Priority: undecided Milestone: 1.5
Component: core Version: 1.4.3
Keywords: ready exception error-handling Cc:
Blocking: Blocked by:

Description

If a ready handler causes an unhandled exception then the ready list will be run twice. I'm testing with 1.4.3 in both Firefox and Safari. e.g.:

jQuery(document).ready(function() {

alert('in ready'); window.frooble();

});

This appears to happen because two callbacks are registered via addEventListener ("DOMContentLoaded" and "load"). The DOMContentLoaded handler cleans up after itself but it doesn't cleanup the load handler as well.

Alternatively, the ready list is null'd out after it is processed instead of making a copy, nulling the original, and only then walking the list.

Change History

comment:1 Changed 3 years ago by SlexAxton

  • Keywords ready exception error-handling added
  • Resolution set to wontfix
  • Status changed from new to closed
  • Component changed from unfiled to core

I don't think jQuery has any history of trying to act nicely when you throw unhandled exceptions. If you might throw an exception, wrap it in a try catch.

comment:2 Changed 3 years ago by hwaara@…

I got bitten by this bug as well! Took hours to figure out the cause that $(document).ready was firing twice. Are you sure this is wontfix?

comment:3 Changed 3 years ago by anonymous

We have also been bitten by this! We tracked it down to a 3rd party plugin throwing an exception. It seems unreasonable for us to have to patch each 3rd party plugin to make them all catch exceptions.

I'm not sure if wontfix is really the right approach here.

comment:4 follow-up: ↓ 5 Changed 3 years ago by nornagon@…

Just wasted an hour and a half stepping through jQuery trying to work out what was going wrong, and this was it. The bug doesn't occur in 1.3.2.

This is a real regression.

comment:5 in reply to: ↑ 4 Changed 3 years ago by rwaldron

Replying to nornagon@…:

Just wasted an hour and a half stepping through jQuery trying to work out what was going wrong, and this was it. The bug doesn't occur in 1.3.2.

This is a real regression.

Test in 1.4.4rc2

k thanks.

comment:6 Changed 3 years ago by Nicolas Cordin <nicolas.cordin@…>

Hi, this is not fix in 1.4.4rc2.

I also think it's a important regression, we have really strange results when we are testing/coding applications.

I lost hours to understand what happend and finding this bug.

comment:7 Changed 3 years ago by rwaldron

Confirmed. But still, I don't think you should hold jQuery responsible for your unhandled exceptions.

 http://jsfiddle.net/rwaldron/S2D5b/1/

comment:8 Changed 3 years ago by buddywilliams@…

I disagree. While jQuery should not "be responsible" for the unhandled exception, it shouldn't as a side-effect create a new exception. This is exactly what is happening here. This means that I cannot trust .ready() because it may actually execute more than once...!?

This is a very undesirable bug especially when considering 3rd party code which you have little or no control over.

I agree that many problems should just be problems until fixed by users but this is a side-effect problem which is dangerous and greatly reduces trust in a much relied on and needed method from jQuery.

comment:9 Changed 3 years ago by localinfidelity@…

I concur with buddywilliams that while jQuery shouldn't cause further problems due to already existing issues. Just ran into this myself and debugged for about an hour until I stumbled across this post.

comment:10 Changed 3 years ago by localinfidelity@…

Nevermind, it appears to be fixed in 1.4.4. Why does the jQuery front page say the latest release is 1.4.3 =/

Please follow the  bug reporting guidlines and use  jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.

View

Add a comment

Modify Ticket

Action
as closed
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.