Side navigation
#7757 closed enhancement (patchwelcome)
Opened December 13, 2010 02:50AM UTC
Closed April 17, 2011 05:44AM UTC
resources loaded when elements are never explicity added to the page document
| Reported by: | tim@bocoup.com | Owned by: | |
|---|---|---|---|
| Priority: | low | Milestone: | 1.6 |
| Component: | manipulation | Version: | 1.4.4 |
| Keywords: | needsreview | Cc: | |
| Blocked by: | Blocking: |
Description
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:
http://dev.aboutnerd.com/test/test.html
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");
Attachments (0)
Change History (11)
Changed December 13, 2010 02:53AM UTC by comment:1
Changed December 13, 2010 03:14AM UTC by comment:2
| component: | unfiled → manipulation |
|---|---|
| keywords: | → needsreview |
| priority: | undecided → low |
| status: | new → open |
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...
<div><h1>BOOM!</h1></div>
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.
Changed December 13, 2010 03:21AM UTC by comment:3
| type: | bug → enhancement |
|---|
Changed December 13, 2010 04:12AM UTC by comment:4
It happens with something as simple as this, not using jQuery at all:
var img = document.createElement("img");
img.src="fetchme.jpg";
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):
http://jsfiddle.net/dmethvin/9pkzW/
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.
Changed December 13, 2010 04:23AM UTC by comment:6
We're aware of the how and why - what Tim is exploring is an alternate method.
Changed January 14, 2011 05:08PM UTC by comment:9
| _comment0: | There is now a duplicate of this, so maybe... we can revisit? → 1295024969502330 |
|---|
Duplicates... maybe we can revisit?
Changed January 14, 2011 09:03PM UTC by comment:10
Changed April 17, 2011 05:44AM UTC by comment:11
| resolution: | → patchwelcome |
|---|---|
| status: | open → closed |
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.
http://jsfiddle.net/lark/YXTkj/
Fiddle demonstrating the erroneously added code at the bottom of the ticket.