1876093 - Iframe gets an empty document.referrer when not in Private

Status: NEW

(Core :: DOM: Service Workers, defect)

Description

[Ivan Kuckir]

Attachment: A screenshot taken in Private Mode.

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36

Steps to reproduce:

My website A: https://www.photopea.com/api/playground has an iframe, which contains another website B: www.photopea.com .

Actual results:

When I open A in a Private mode, the website B can access document.referrer.
When I open A in a regular mode, the website B sees document.referrer as "".

Expected results:

I think the website B should be able to see the document.referrer. They are even on the same origin in this case.

It works correctly in Private mode, so I have to ask my users to use Firefox in Private mode.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::Private Browsing' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Tim Huang[:timhuang]]

I tried to reproduce the issue but can still get the referrer. Maybe it's because of some change in your settings. Would you be able to provide your troubleshooting info on the about:support page for us to diagnose this issue? Thank,

Comment 3

[Ivan Kuckir]

UPDATE: the document.referrer is available in B, if A is opened for the first time. If you open it for the second, third time ... it stops working. Clearing website data will make it work again. Could you try the steps again?

I have reinstalled Firefox to default settings, it still happens.

Comment 4

[rbrtcs1]

I am seeing the same problem - Mac 12.1 - Firefox 122.0 Build 20240118164516

I can confirm that the iframe network request did correctly include the 'referer' header - but the inner page is not able to access document.referrer via javascript (it's value is an empty string).

When switching to private browsing it works though - the document.referrer attribute is set correctly.

Comment 5

[Negritas Sergiu, Desktop QA]

Hello! I have tried to reproduce the issue on my end with firefox 124.0a1(2024-01-25) on Ubuntu 22.04. On my end I have managed to get on the doccument.referrer as "" in both normal and private browsing.

Could you please answer the following question in order to further investigate this issue

1. Does this issue happen with a new profile? Here is a link on how to create one: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles
2. Does this issue happen in the latest nightly? Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/
3. Do you have any addons installed? If yes could you please list them?

Comment 6

[Ivan Kuckir]

Sorry, I am using the latest stable Firefox 122.0. Could you try it in Firefox 122.0? Could you change my original report?

Comment 7

[Tim Huang[:timhuang]]

I investigated this issue a bit. The service worker's interception causes the missing referrer. It looks to me that the referrer header doesn't get cloned in the service worker code. I tested this using Chrome, and it works fine for the referrer header. I am unsure if this is expected because I am unfamiliar with the behavior of service workers for interception fetches here.

Andrew, is this an expected behavior or a regression? Thank.

Comment 8

[Andrew Sutherland [:asuth] (he/him)]

Seems like it's a bug. Specifically, the site serviceworker currently has the fetch handler:

self.addEventListener('fetch', function() {
    return;
});

which means that we basically have a channel situation that looks like:

• nsHttpChannel redirects to...
• InterceptedHttpChannel for interception which when respondWith is not called on the FetchEvent, we ResetInterception to a new...
• nsHttpChannel.

In ResetInterception we call into HttpBaseChannel::SetupReplacementChannel which calls into HttpBaseChannel::CloneReplacementChannelConfig which has specific handling for mReferrerInfo.

There is logic in there that special-cases on DocumentChannel to just propagate the existing mReferrerInfo without considering the current referrer policy based on aReplacementReason==HttpBaseChannel::ReplacementReason::DocumentChannel but not for internal redirects. The else branch does handle HSTS but it looks like HSTS is REDIRECT_PERMANENT |REDIRECT_STS_UPGRADE so I guess I'm a little surprised that internal redirects aren't handled the same way as DocumentChannel? Like what internal redirect would want the referrer policy applied? If there are some that want it applied, maybe InterceptedHttpChannel should get its own ReplacementReason value or something.

Valentin, do you have thoughts on this / can you redirect to someone? Thanks!

Comment 9

[Andrew Sutherland [:asuth] (he/him)]

(moving to ServiceWorkers)

Comment 10

[Valentin Gosu [:valentin] (he/him)]

(In reply to Andrew Sutherland [:asuth] (he/him) from comment #8)

The else branch does handle HSTS but it looks like HSTS is REDIRECT_PERMANENT |REDIRECT_STS_UPGRADE so I guess I'm a little surprised that internal redirects aren't handled the same way as DocumentChannel? Like what internal redirect would want the referrer policy applied? If there are some that want it applied, maybe InterceptedHttpChannel should get its own ReplacementReason value or something.

Valentin, do you have thoughts on this / can you redirect to someone? Thanks!

I don't remember why things are like this, but it seems like a different reason for intercepted channels would be a reasonable approach.
I agree that having a different referrer policy internal redirects seems weird, but I'm not sure if that was intentional.
Maybe Freddy can direct us to someone who knows.

Comment 11

[Frederik Braun [:freddy]]

Looks like this is connected to ETP referrer stripping? I found https://bugzilla.mozilla.org/show_bug.cgi?id=1589407 and https://bugzilla.mozilla.org/show_bug.cgi?id=1601743.

I hope Tim can help.

Comment 12

[Tim Huang[:timhuang]]

I don't think the logic that Andrew mentioned in comment 8 is related to ETP referrer stripping. The ETP referrer stripping has nothing to do with the HTTP redirect.

I also don't know why we handle the internal redirects this way. Maybe it's something we missed before. Generally speaking, I agree that we should have a reason for intercepted channels so we can properly handle referrer info for intercepted redirects.