User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0 Steps to reproduce: in about:preferences, in the "Tabs" section, deselect "Open links in tabs instead of new windows". Create a web page with a link to another website. The link element should include the attributes: target="_blank" and rel="noopener". Please see attached html file. Then use Firefox to click the link on the page. Actual results: The link opens in a new window, and the window.opener object is not accessible in the new window, as is expected by the use of the rel="noopener" attribute. However, the HTTP_REFERER header is not sent as part of the HTTP request, and the document.referrer string is not available in the DOM on the new page. Note that if the "Open links in tabs instead of new windows" option is selected, then the referrer is properly sent. Expected results: The link should be opened in a new window and the HTTP_REFERER should be sent as normally happens when a link is clicked.
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0 (20181030100414) I'm able to reproduce the mentioned behavior on Windows 10 x64 using the latest Nightly and Fx release builds. When following the provided steps I can see the HTTP_REFERER header is not sent as part of the HTTP request and the document.referrer string is not available in the DOM on the new page.
Nick -- please have a look and open a DOM bug if needed.
Priority: -- → P2
So I haven't been able to 100% track this down as there's JS on the stack, and either "call DumpJSStack()" doesn't work in gdb any more, or I'm Doing It Wrong (tm). Either way, I can say with certainty that the docshell on the child process is not being given a refer(r)er, and so it never sets the refer(r)er on the channel. So of course we can't send the Referer header! Beyond that, it's unclear to me where, exactly, the responsible code is. Going with DOM as a first guess.
Component: Networking: HTTP → DOM
Priority: P2 → --
Neha, can your team take a look at this?
Priority: -- → P3
Discussed with Wennie about this and Wennie suggested Christoph Kerschbaumer to take a look at it.
Flags: needinfo?(nkochar) → needinfo?(ckerschb)
(In reply to nkochar from comment #5) > Discussed with Wennie about this and Wennie suggested Christoph Kerschbaumer > to take a look at it. Thomas, can you please investigate and fix? Thanks!
Assignee: nobody → tnguyen
Status: NEW → ASSIGNED
Priority: P3 → P1
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #6) > (In reply to nkochar from comment #5) > > Discussed with Wennie about this and Wennie suggested Christoph Kerschbaumer > > to take a look at it. > > Thomas, can you please investigate and fix? Thanks! Taking a look, thanks for reporting this bug :)
I just created a test page based on your test and Firefox works as expected. https://tungmangtdh3.github.io/ I took a look again at the test here to see what happens and I found that bugzilla.mozilla.org responded a header "Referrer-Policy: same-origin" That makes the HTTP_REFERER will not be sent. Note that when you click the link, you are going to navigate to https://bugzilla.mozilla.org/test1.html from https://bug1502678.bmoattachments.org/attachment.cgi?id=9020561, cross origin So the "same-origin" policy will not allow us to send referrer header. Stefan, could you please confirm that?
The only thing here that may be concerned here is should we check and apply referrer policy to document.referrer when redirecting. I guess that would be a potential problem there.
FWIW, I tried to reproduce this on macOS outside of Bugzilla (using https://software.hixie.ch/utilities/js/live-dom-viewer/ and following the comment 0 instructions of changing the preference) and couldn't. There was always a correct referrer.
I can confirm I see a warning in the console saying when using the test1 page from comment 0 "Same Origin policy disallows reading the remote resource at *link* ( Reason: CORS request dis not succeed)". With the test page from comment 9, the warning is not observed and the HTTP_REFERRER is sent as a part of the HTTP request.
Well, that is because https://bugzilla.mozilla.org/test1.html respond with "same-origin" Referrer Policy header and I don't see wrong behavior here. I will create an automation test tomorrow then we can close this.
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/c7927056a2a2 Add an automated test to test referrer header is sent correctly in target=_blank and rel=noopener. r=ckerschb
You need to log in before you can comment on or make changes to this bug.