148268 - no referrer from javascript-created windows

Status: VERIFIED DUPLICATE of bug 157796

(Core :: Networking: HTTP, defect)

Description

[Abe Nelson]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
BuildID:    2002041711

javascript created pages (windows) will not send a referrer when requesting 
needed resources to display in the created page.

This breaks some sites that rely on the referrer header to protect bandwidth 
and restrict resources.

Reproducible: Always
Steps to Reproduce:
1.Create page with javascript that spawns another page (window) with other 
resources needed (via document.write, etc...)
2.Load this page, which will spawn the new page.

Actual Results:  Logs will show no referrer for the requested resources of the 
new page (window)

Expected Results:  send the referrer of the URL that created the new page 
(window); this should be considered a sub-set of the original page, and of the 
site.

IE does this as expected. Sites that depend on this will not be able to support 
Mozilla without this.

Comment 1

[Darin Fisher]

jst, rick, radha: any idea how to fix this one?

Comment 2

[Boris Zbarsky [:bzbarsky]]

So.  You do

window.open("http://foo");

and expect the request for "http://foo" to send the current page as referer?

Comment 3

[Radha on family leave (not reading bugmail)]

I think, in  nsHTMLDocument.cpp, when we create the nsWyciwygChannel and send
out the request, we have to set the current page as referrer. The current page
info can be obtained from the docshell. 

Comment 4

[Jesse Ruderman]

I think this is a dup of bug 123293.

Comment 5

[Keyser Sose]

dupe

*** This bug has been marked as a duplicate of 123293 ***

Comment 6

[Abe Nelson]

123923 seems to deal with having wysiwyg:// referrers, what I'm talking about is
the fact that some resources send the referrer while others don't ie.
javascript-written IMG tags send a referrer, but javascript-written EMBED tags
do not. Both are objects of a page that need to be fetched from a server. Why is
EMBED being treated differently.

This behavior seems inconsistent to me.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Reopening.  Comment 0 and comment 6 need to be reconciled (because they are not
saying the same thing at all, as far as I can see).  Simply posting a testcase
would help there....

In either case, this is not bug 123293

Comment 8

[Abe Nelson]

Actually, I discovered that this isn't a JS-secific issue. Coincidently, a new 
(more descriptive) bug report that deals with this issue has recently been 
submitted (which also includes a test-case): 157796

Comment 9

[Boris Zbarsky [:bzbarsky]]

Abe, would you mind if I mark this duplicate of bug 157796 then?  If that bug
exactly describes the problem and has more details (as well as the right
assignee) then....  If that does not fully describe the problem you reported,
however, we should not mark this duplicate.

Comment 10

[Abe Nelson]

The new bug report deals exactly with the problem I reported. Go ahead and mark 
this one as a dup.

Comment 11

[Matthias Versen [:Matti]]

*** This bug has been marked as a duplicate of 157796 ***

Comment 12

[John Unruh]

Verified duplicate.