Skip to main content

Bug Tracker

Side navigation

#10138 closed bug (invalid)

Opened August 25, 2011 06:18PM UTC

Closed August 25, 2011 09:01PM UTC

Last modified August 26, 2011 01:35PM UTC

Delayed remove throws exception in webkit

Reported by: davestein Owned by:
Priority: undecided Milestone: None
Component: unfiled Version: 1.6.2
Keywords: Cc:
Blocked by: Blocking:
Description
Attachments (0)
Change History (5)

Changed August 25, 2011 06:20PM UTC by davestein comment:1

I have another spot in my code base where .remove() is throwing an exception but have been unable to replicate in a simple fiddle. More about it is on stackoverflow:

http://stackoverflow.com/questions/7114368/why-is-jquery-remove-throwing-attr-exception-in-ie8

Changed August 25, 2011 09:01PM UTC by dmethvin comment:2

resolution: → invalid
status: newclosed

Here is a simplified repro without jQuery:

http://jsfiddle.net/dmethvin/cZ9hN/12/

At the point where the timeout fires, e.target is no longer in the DOM because the blur handler removed it. Webkit doesn't like that, and I think it has a point:

removeChild - Removes the child node indicated by oldChild from the list of children, and returns it. Exceptions: NOT_FOUND_ERR: Raised if oldChild is not a child of this node.

http://www.w3.org/TR/DOM-Level-2-Core/core.html

Trying to use the results of the event object (in this case e.target) after the event is delivered is always dicey.

Changed August 25, 2011 10:24PM UTC by davestein comment:3

If user is trying to remove something that is removed, should it throw an exception? If I do $('#el').remove() randomly on something that does not exist, jQuery does not throw an exception yet in this use case it would - despite the element not existing both times.

Changed August 26, 2011 12:49AM UTC by dmethvin comment:4

My opinion is that the app logic here is shaky. The original code even fired off the setTimeout on *every* keystroke, forcing the need for a closure, even though it only needed to do so for the Enter key.

This is not a jQuery issue. The code has cached a reference to an element that was removed from the DOM a few milliseconds before. You might try bringing that test case to the attention of the Webkit team and see if they believe anything is wrong with their implementation, for example whether .parentNode should have been nulled on the input before the timeout occurred.

Changed August 26, 2011 01:35PM UTC by Dave Stein <be.davestein@gmail.com> comment:5

Yeah I think you have a good point there. For instance in Firebug if I click on the element, it still "existed" but with no parent so the HTML tab would show it greyed out floating by itself. Meanwhile with a console log in webkit, it still had parentNode magically which prevented me from determining it was a reference to a removed node.