649294 - <img> inside document.written <noscript> after one earlier single-level document.write preloaded

Status: RESOLVED DUPLICATE of bug 642908

(Core :: DOM: HTML Parser, defect)

Description

[Vincent de Lagabbe]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0

When the attached code is executed in Firefox 4 (with javascript on), the noscript part is fired (the embedded img is called - use firebug or fiddler), why?

This does not happen in Firefox3 (any version), Chrome, IE...

Reproducible: Always

Steps to Reproduce:
1. Enable javascript support in the browser
2. Execute the snippet provided with a HTTP traffic analyser such as fiddler
3. Check your HTTP traffic analyser

Actual Results:  
the img tag is requested by Firefox4

Expected Results:  
the noscript part should not be executed (img tag should not load)

if the line 6 ( document.write ("<scr"+"ipt type='text/javascript' src='http://www.lalalalallalalalala.com'></scr"+"ipt>" );) is commented out or removed, the behaviour is correct (noscript is not executed)

Comment 1

[Vincent de Lagabbe]

Attachment: Noscript execution demo

Comment 2

[AndreiD[QA]]

In reply to comment #1:
Demo is not working

Comment 3

[Vincent de Lagabbe]

(In reply to comment #2)
> In reply to comment #1:
> Demo is not working

Have you followed the step above? Do not expect to see anything in the page. The problem is the HTTP request to the image declared in the noscript part. You'll see it if you use a traffic analyser (fiddler, firebug, httpfox ...)

Comment 4

[Vincent de Lagabbe]

Attachment: Demo result (using http fox)

Check the last line in httpfox output: a HTTP request to the image embedded in the noscript part is fired during code execution

Comment 5

[Loic Chambard]

If this issue is confirmed, it can be a big problem for all the web advertising world.

Indeed, most of the advertiser ad tags have a NoScript part, and they are often inserted into a JavaScript on the publisher side. If the JS and the NoScript are triggered together, the advertiser side will count the ad impression twice, leading to wrong reports and discrepancies.

Comment 6

[Boris Zbarsky [:bzbarsky]]

This looks like a duplicate of bug 642908.  Henri, can you confirm?  I'm not sure what qualifies as "multi-level document.write"...

Comment 7

[Loic Chambard]

Thanks for the reply Boris.
Indeed, it seems like the same issue.

But how can you consider that as a non-issue?
As Mike Cherichetti was explaining in the other bug, it's a really common behavior to have a noscript embedded in a document.write. Adserving systems are often using overlap scripts (main publisher script calling 3rd party script, calling 3rd party...).

This is a big problem for lots of advertising companies as it can mess up all ad reporting and inventory management system. I'm sure you'll see some big ad companies (Google, Yahoo...) complaining when they we'll realize it.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> it's a really common behavior to have a noscript embedded in a document.write. 

Sure.  I don't understand _why_, since that's a completely pointless thing to do (if your write() call happens, then clearly script is enabled), but I accept this is happening.

If we considered this a non-issue, that bug would be marked invalid, not wontfix.

If we get complaints about the issue, we'll probably at least reconsider the wontfix in bug 642908...  But as I pointed out in that bug, the fundamental assumptions people are making are just broken.  Those are not the semantics GET requests have and never have been; there were _always_ cases when the number of GET requests for an <img> in a page would be more or less than 1...

Comment 9

[Vincent de Lagabbe]

(In reply to comment #8)
> > it's a really common behavior to have a noscript embedded in a document.write. 
> 
> Sure.  I don't understand _why_, since that's a completely pointless thing to
> do (if your write() call happens, then clearly script is enabled), but I accept
> this is happening.

The answer to the "_why_" is easy: people copy/paste code in their CMS and don't understand what's happening behind. Beside, it's very rare in the advertising world to be integrated at the top level of a page, usually you end up in an undetermined number of nested javascripts/iframe calls. Only the big players (Google) have the power to be integrated top level on the publisher they are working with. They simply say "if we are nested, then we won't work with you". Works for them, not for the little ones...

For the others, you often need to become *very* creative when you want to do some complicated things :-)
 
> If we considered this a non-issue, that bug would be marked invalid, not
> wontfix.
> 
> If we get complaints about the issue, we'll probably at least reconsider the
> wontfix in bug 642908...  But as I pointed out in that bug, the fundamental
> assumptions people are making are just broken.  Those are not the semantics GET
> requests have and never have been; there were _always_ cases when the number of
> GET requests for an <img> in a page would be more or less than 1...

I totally agree with you on this point, but nobody found (yet) a better way to track your own code execution (or non execution) on a website that you don't control.

Comment 10

[Henri Sivonen (:hsivonen)]

(In reply to comment #6)
> This looks like a duplicate of bug 642908.  Henri, can you confirm?  I'm not
> sure what qualifies as "multi-level document.write"...

This isn't quite a duplicate in the sense that the test case here doesn't have multi-level document write. I'll have to take a closer look in a debugger to see what's happening here.

(In reply to comment #9)
> I totally agree with you on this point, but nobody found (yet) a better way to
> track your own code execution (or non execution) on a website that you don't
> control.

You aren't testing "execution". The stuff inside <noscript> is not executed as JavaScript. It doesn't even create an image element in the document. It is only causing an image prefetch using HTTP GET. Servers shouldn't consider extra GETs to represent any user action. Please see section 9.1.1 Safe Methods of the HTTP spec:
http://tools.ietf.org/html/rfc2616#section-9.1.1

Comment 11

[Henri Sivonen (:hsivonen)]

(In reply to comment #10)
> (In reply to comment #6)
> > This looks like a duplicate of bug 642908.  Henri, can you confirm?  I'm not
> > sure what qualifies as "multi-level document.write"...
> 
> This isn't quite a duplicate in the sense that the test case here doesn't have
> multi-level document write. I'll have to take a closer look in a debugger to
> see what's happening here.

There's a bug here after all. Patch in bug 642908.

Comment 12

[Vincent de Lagabbe]

Thanks a lot for the fix!