Skip to main content

Bug Tracker

Side navigation

#12047 closed bug (wontfix)

Opened July 10, 2012 07:17AM UTC

Closed July 12, 2012 03:06PM UTC

Last modified July 12, 2012 04:54PM UTC

body.removeChild( container ); can cause an error

Reported by: Ian Yang Owned by: Ian Yang
Priority: low Milestone: None
Component: support Version: 1.7.2
Keywords: Cc:
Blocked by: Blocking:

An answer of a question on stackoverflow shows that jQuery adds some elements (the outmost one is container) to do some tests (line 1537 in the un-minified version):

// Run tests that need a body at doc ready
jQuery(function() {
var container, outer, inner, table, td, offsetSupport,

And at line 1654 jQuery wants to remove that test element with:

body.removeChild( container );

However, as addressed in the question, by using the DOMNodeInserted event, all contents of body can be wrapped inside another element before jQuery can remove that test element, causing body.removeChild( container ); to fail because the container isn't a child element of body anymore.

So the suggestion is to change line 1654 into:

jQuery( container ).remove();
Attachments (0)
Change History (8)

Changed July 10, 2012 01:51PM UTC by timmywil comment:1

component: unfiledsupport
priority: undecidedlow
resolution: → wontfix
status: newclosed

DOMNodeInserted is deprecated and should no longer be used.

Changed July 12, 2012 12:50PM UTC by dmethvin comment:2

#12066 is a duplicate of this ticket.

Changed July 12, 2012 12:51PM UTC by dmethvin comment:3

resolution: wontfix
status: closedreopened

Changed July 12, 2012 12:52PM UTC by dmethvin comment:4

owner: → Ian Yang
status: reopenedpending

Can you provide a test case on jsFiddle that reproduces the issue, not using the deprecated DOMNodeInserted?

Changed July 12, 2012 01:37PM UTC by Ian Yang <> comment:5

Replying to [comment:4 dmethvin]:

Can you provide a test case on jsFiddle that reproduces the issue, not using the deprecated DOMNodeInserted?

Here is the test case on jsFiddle. Please use the Firebug on Firefox 13 to see the error. And please click on the "Run" button to run it again if you don't see the error. On jsFiddle, the chance of this happening is 50%.

Note: the technique used in the test case is inspired by this article.

Changed July 12, 2012 03:06PM UTC by gibson042 comment:6

resolution: → wontfix
status: pendingclosed

Support loads before most other modules, in particular manipulation, so that line can execute before .remove is defined. And more importantly, we're just not prepared to tolerate external manipulation of our internal-use elements.

Changed July 12, 2012 04:06PM UTC by dmethvin comment:7

We could get around the error sans jQuery with container.parentNode.removeChild(container) but I don't think that resolves the issue -- it only hides it. If you are wrapping the HTML we use to do feature detects it is going to affect the outcomes, and cause jQuery to misbehave in strange ways down the road. The workaround would be do not attach your DOMNodeInserted handler until document ready, since we attach our ready handler for support checks first.

Changed July 12, 2012 04:54PM UTC by Ian Yang <> comment:8

Thanks for the advise anyway.

Btw, I have no intention of manipulating anyone's internal-use elements. I won't even know they exist if they didn't cause my browser to throw the error.