Bug Tracker

Opened 6 years ago

Closed 6 years ago

#7757 closed enhancement (patchwelcome)

resources loaded when elements are never explicity added to the page document

Reported by: tim@… Owned by:
Priority: low Milestone: 1.6
Component: manipulation Version: 1.4.4
Keywords: needsreview Cc:
Blocked by: Blocking:


The two most common cases I've thought of within jQuery that demonstrate this bug exist in the constructor and the fn.load method. A live example of the load method can be found on my dev site:


Use resource tracking to see the img resource requested and subsequently 404'd. This occurs even though a selector was provided and the content was filtered so that the img was never explicitly added into the page.

Using a browser console and entering in the following in page with jQuery included you will see the img requested and 404'd even though it was never explicitly added to any elements in the page.

$("<div><h1></h1><img src='404.jpg'/></div>").find("h1");

Change History (11)

comment:1 Changed 6 years ago by tim@…


Fiddle demonstrating the erroneously added code at the bottom of the ticket.

comment:2 Changed 6 years ago by Rick Waldron

Component: unfiledmanipulation
Keywords: needsreview added
Priority: undecidedlow
Status: newopen

While Tim worked on this discovery, I can definitely confirm the behaviour. It might be edge case - its even difficult to create a fiddle for it. But for clarity sake...

Assume I have an HTML file and it has a div in the body. Additionally, I have a script tag that does this:

$('div').load('file.html h1');

And in file.html...

<h1>BOOM!</h1><img src="404.jpg">

The result of the load() call will look like this...


So far so good... But I check the JS Console, I will see a 404 error has been logged for that image tag that has a src set to an image file that does not exist. But I did not ask for this image, I only asked for the H1.

While it makes sense that jQuery will turn the entire response into a dom fragment that it can then filter the contents of - this could have very serious and unexpected behaviour.

The floor is now open for discussion.

comment:3 Changed 6 years ago by Rick Waldron

Type: bugenhancement

comment:4 Changed 6 years ago by dmethvin

It happens with something as simple as this, not using jQuery at all:

var img = document.createElement("img");

Both IE and Firefox fetch the image immediately, and if they're appended to a document that had a base tag they don't re-fetch based on the new url (I used Fiddler on Windows to see the actual requests):


Chrome and Safari seem to wait until the image is appended to the document so they get the base href correct.

AFAICT this is something totally out of our control.

comment:5 Changed 6 years ago by dmethvin

See also #6212, IE6 fetches the image twice.

comment:6 Changed 6 years ago by Rick Waldron

We're aware of the how and why - what Tim is exploring is an alternate method.

comment:7 Changed 6 years ago by jitter

#7823 is a duplicate of this ticket.

comment:8 Changed 6 years ago by Rick Waldron

#7971 is a duplicate of this ticket.

comment:9 Changed 6 years ago by Rick Waldron

There is now a duplicate of this, so maybe... we can revisit?

Version 0, edited 6 years ago by Rick Waldron (next)

comment:10 Changed 6 years ago by pere.cil@…

I'm not sur #7971 is a duplicate of this bug. In, #7971 what i'm asking is not to reload javascripts resources from previously loaded page.

comment:11 Changed 6 years ago by john

Resolution: patchwelcome
Status: openclosed

I'm not sure if this is really something that we can tackle on a fundamental level - at best it would require moving away from Document Fragments - but even then it's not clear if that would actually help (the same result would likely still happen with just innerHTML stuff). I'm going to close this as 'patchwelcome' to see if anything pops up in particular.

Note: See TracTickets for help on using tickets.