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

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.

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.

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.

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.