Closed Bug 48902 Opened 24 years ago Closed 23 years ago

Referer: not sent with "Open Link in New Window"


(SeaMonkey :: UI Design, defect, P1)



(Not tracked)



(Reporter: kentt, Assigned: bzbarsky)




(Keywords: testcase)


(1 file)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20000813
BuildID:    2000081308

When inside a site that prevents hotlinking of its files by using .htaccess,
opening a link using "Open Link in New Window" causes the server to respond as
if you either followed a link from an external source or manually typed the url
in the adress bar.

Reproducible: Always

Additional Info:
.htaccess example

RewriteEngine On
RewriteCond %{HTTP_REFERER} !^ [NC]
RewriteRule /* [L,R]

This will reroute all links that are NOT at the domain to

However, if you open a link at using "Open Link in New Window" you
will also get rerouted.
setting bug status to New
Ever confirmed: true
Target Milestone: --- → Future
Blocks: 61660
http bugs to "Networking::HTTP"
Assignee: gagan → darin
Component: Networking → Networking: HTTP
Target Milestone: Future → M19
The referrer is also not sent when clicking on a link that opens a new window

Steps to Reproduce:
1) Visit and click on the XHTML 1.0 icon at the
bottom of the page.

Actual Results:
The referrer is not sent to the page that opens in a new window. As a result,
W3C's HTML Validator redirects to the default page asking for a url.

Expected Results:
The page opening in the new window should receive the referrer. The results page
for the validation check of should be displayed in
the new browser window.

Build Date & Platform:
2001011120 win32-talkback on Windows 98 4.10.1998
Blocks: 61426
Target Milestone: --- → Future
Severity: normal → major
Keywords: mozilla0.9
This should not be future.  It breaks numerous porn sites.  (Increasing 
severity to major and nominating for mozilla0.9.)
Looks like someone's forgetting to set the referrer on their HTTP channel.
mscott?  any ideas where this problem might be?
Assignee: darin → mscott
Component: Networking: HTTP → Layout
should this belong in Layout? [cc'ing karnaze]

clearing milestone to renominate it [per Jesse's comment above].
Target Milestone: Future → ---
Changing component to networking: HTTP
Component: Layout → Networking: HTTP
This is breaking sites, catfood.
Keywords: nsbeta1, nsCatFood
From bug 76322 which I belive is a dup:
Javascript that displays the referrer.  There is no referrer when
opened in new window.

*** Bug 76322 has been marked as a duplicate of this bug. ***
I think this is an XPFE thing so I'm reassigning and bumping the priority. 

The simple reason there is no referrer is because the JS that opens the code has 
no concept of referrer and new navigator windows have no concept of referrer.  
JS that opens new windows is here:

The function should take a referrerUrl as a second parameter and be able specify 
it to window.openDialog, such by appending it to the third parameter. e.g.

newWin = window.openDialog( getBrowserURL(), "_blank", 
"chrome,all,dialog=no,referrer=" + referrerUrl, url, null, true );

The new navigator window can then pluck out the referrerUrl from the args when 
it is initialising itself and ensure it is set correctly when browsing to the 
url commences.
Component: Networking: HTTP → XP Apps
Priority: P3 → P2
Assignee: mscott → pchen
QA Contact: tever → sairuh
nav triage: moving to mozilla0.9.2. 
Priority: P2 → P4
Target Milestone: --- → mozilla0.9.2
*** Bug 81645 has been marked as a duplicate of this bug. ***
nav triage team:

Pushing out to mozilla0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Summary: No http referrer when opening link in new window → Referer: not sent with "Open Link in New Window"
'Referer' not sent with embeded images (<img/>) http request.

for an html file that contains :
...<img SRC="tomcat.gif" height=92 width=130 align=LEFT>...

the http request that goes back to the server to get the images in the html file
doesn't have a 'referer' param. (IE does that.)
GET /tomcat.gif HTTP/1.1
Host: localhost:81
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9) Gecko/20010505
Accept: */*
Accept-Language: en
Accept-Encoding: gzip,deflate,compress,identity
Accept-Charset: ISO-8859-1, utf-8; q=0.667, *; q=0.667
Keep-Alive: 300
Connection: keep-alive

gaxzero: sending referer for images is covered by bug 74284.
nav triage -> mozilla1.0
Target Milestone: mozilla0.9.3 → mozilla1.0
I have created a very simple testcase that shows whether the problem has been
fixed (in version 0.9.2 it still exists)

Look at to see if the problem still exists with
your current build of Mozilla.

The correct result when opening the link presented there in a new window should be:

HTTP referrer field: ''

The actual result at this moment (0.9.2 on Win2K or Linux and probably all other
platforms/OSes) is:

HTTP referrer field: ''

The bug is really irritating as it keeps me from opening new windows on some
sites I frequent.
I've got half of what I need to fix this from adamlock's comment; I just now
need someone to tell me where openDialog is implemented. Anyone?


vishy: how can this be nsbeta plussed but not nscatfood?

+ testcase

Thanks for your contribution!
Gerv - I think Jag is familiar with the open new window code ( :-) )
and can help killing this. Adding him to Cc. Wish to take the bug? 
rpotts: here's one for you! I don't think Paul is working on this... :-) Feel
I think that a fix for this bug will fall out of the patches for bug #94205.

These patches will add a 'referer' argument to nsIWebNavigation::LoadURI(...) 
which will allow code which opens up new windows to *actually* set a referer...
Depends on: 94205
-> rpotts

'cause i'm a glutton for punishment ;-)
-> rpotts

'cause i'm a glutton for punishment ;-)

(this time for real!!!)
Assignee: pchen → rpotts
*** Bug 101478 has been marked as a duplicate of this bug. ***
*** Bug 101478 has been marked as a duplicate of this bug. ***
*** Bug 103915 has been marked as a duplicate of this bug. ***
*** Bug 105273 has been marked as a duplicate of this bug. ***
Blocks: 107162
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
Target Milestone: mozilla1.0 → mozilla1.0.1
+mozilla1.0, bagged catfood (ironically, I was cat sitting for a while, but not
anymore. Catfood doesn't do anything for me anymore).

This header is used enough where we should get this right for Mozilla 1.0.
Keywords: nsCatFood-mozilla1.0
someone should also change the target milestone to mozilla1.0. I would, but
don't have access.
Clearing target milestone to re-nominate for mozilla1.0 (it was 1.0, but was
auto-pushed to 1.0.1 by Asa)

pbaker: can't set a target milestone for someone else, it's a statement of when
the assignee thinks they'll get to it. If it's set too late for you all you can
do is lobby or find someone else who might be able to do it sooner.
Target Milestone: mozilla1.0.1 → ---
This also happens when you open a link in a new tab.
i get this behavior on linux, so i think the OS field should be revised.
OS->all per #37
OS: Windows 2000 → All
Blocks: 120721
Attached patch Proposed patchSplinter Review
Sends "Referer" with open link in new window, open link in new tab, middle
click to open in new window or tab, ctrl-click to open in new tab.
Reviews?  You can use to
test, in addition to the testcase already listed in this bug...
Keywords: patch, review
in the contentAreaClick.js part, you have twice:

+          theTab =
+            getBrowser().addTab(href,
+                                getReferrer(document)); // open link in new tab

I think that can safely go into one line

Comment on attachment 65748 [details] [diff] [review]
Proposed patch

Attachment #65748 - Flags: superreview+
Comment on attachment 65748 [details] [diff] [review]
Proposed patch

r=doron with the above mentioned nit
Attachment #65748 - Flags: review+
taking this; will land once tree reopens for 0.9.9
Assignee: rpotts → bzbarsky
Priority: P4 → P1
Target Milestone: --- → mozilla0.9.9
Blocks: 119478
*** Bug 120721 has been marked as a duplicate of this bug. ***
checked into trunk
Closed: 23 years ago
Resolution: --- → FIXED
Verified, build 2002-01-24-06, Win2k. :-)
*** Bug 122161 has been marked as a duplicate of this bug. ***
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.