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} !^http://mysite.com/ [NC] RewriteRule /* http://www.yahoo.com [L,R] - This will reroute all links that are NOT at the mysite.com domain to www.yahoo.com. However, if you open a link at mysite.com using "Open Link in New Window" you will also get rerouted.

setting bug status to New

http bugs to "Networking::HTTP"

Overview: The referrer is also not sent when clicking on a link that opens a new window (target=_blank). Steps to Reproduce: 1) Visit http://www.givetheworld.net/ 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 http://www.givetheworld.net/ should be displayed in the new browser window. Build Date & Platform: 2001011120 win32-talkback on Windows 98 4.10.1998

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?

should this belong in Layout? [cc'ing karnaze] clearing milestone to renominate it [per Jesse's comment above].

Changing component to networking: HTTP

This is breaking sites, catfood.

From bug 76322 which I belive is a dup: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=30564 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: http://lxr.mozilla.org/seamonkey/source/xpfe/communicator/resources/content/cont entAreaUtils.js#40 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.

Reassign

nav triage: moving to mozilla0.9.2.

*** Bug 81645 has been marked as a duplicate of this bug. ***

nav triage team: Pushing out to mozilla0.9.3

'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

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 http://www.havinga.nu/test.html 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: 'http://www.havinga.nu/test.html' 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? Gerv

OpenDialog is at http://lxr.mozilla.org/seamonkey/source/dom/src/base/nsGlobalWindow.cpp#2290 which call OpenInternal, found at http://lxr.mozilla.org/seamonkey/source/dom/src/base/nsGlobalWindow.cpp#3059 but it looks like the actual option processing happens down at http://lxr.mozilla.org/seamonkey/source/embedding/components/windowwatcher/src/ nsWindowWatcher.cpp

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 free...

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...

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

-> rpotts 'cause i'm a glutton for punishment ;-) (this time for real!!!)

*** 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. ***

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 moved)

+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.

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.

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

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 http://www.zbarsky.org:8000/~bzbarsky/referrerTest.html to test, in addition to the testcase already listed in this bug...

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 sr=hyatt

Comment on attachment 65748 [details] [diff] [review] Proposed patch r=doron with the above mentioned nit

taking this; will land once tree reopens for 0.9.9

*** Bug 120721 has been marked as a duplicate of this bug. ***

checked into trunk

Verified, build 2002-01-24-06, Win2k. :-)

*** Bug 122161 has been marked as a duplicate of this bug. ***