XHR in Worker scripts does not use correct referrer-policy

NEW
Unassigned

Status

()

defect
P2
normal
2 years ago
2 months ago

People

(Reporter: bkelly, Unassigned)

Tracking

(Blocks 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Workers should get their own referrer policy based on their main script load headers.  Our XHR code, however, always tries to set the referrer policy based on the worker's associated window document.  This is the page that created the dedicated worker or nullptr for SharedWorker/ServiceWorker.

https://dxr.mozilla.org/mozilla-central/source/dom/xhr/XMLHttpRequestMainThread.cpp#2569

In any case, it looks like our referrer policy is always wrong for XHR inside Worker scripts.
For fetch(), the worker referrer policy is saved off on the Request object here:

https://dxr.mozilla.org/mozilla-central/source/dom/fetch/Request.cpp#435

We don't do anything similar for XHR afaict.
Hi Thomas, I know you've been working on referrer policy, is this at your wheelhouse and that you would be able to take a look?
Flags: needinfo?(tnguyen)
I have some long term plans to get this information from the Client primitives I'm adding in bug 1293277, but I'd be happy to see a short term solution as well.

Comment 4

2 years ago
Sure, I will take a look at this.
Flags: needinfo?(tnguyen)
Priority: -- → P2

Comment 5

2 years ago
(In reply to Ben Kelly [not reviewing due to deadline][:bkelly] from comment #0)
> Workers should get their own referrer policy based on their main script load
> headers.  Our XHR code, however, always tries to set the referrer policy
> based on the worker's associated window document.  This is the page that
> created the dedicated worker or nullptr for SharedWorker/ServiceWorker.
> 
> https://dxr.mozilla.org/mozilla-central/source/dom/xhr/
> XMLHttpRequestMainThread.cpp#2569
> 
> In any case, it looks like our referrer policy is always wrong for XHR
> inside Worker scripts.

You are right, thanks for reporting.
(In reply to Ben Kelly [not reviewing due to deadline][:bkelly] from comment #3)
> I have some long term plans to get this information from the Client
> primitives I'm adding in bug 1293277, but I'd be happy to see a short term
> solution as well.

It would be perfect if we have "JavaScript global environment’s referrer policy" as spec, or a Client interface as your long term is also a great solution.
For the short term, I would prefer adding an "environment referrer policy" in XMLHttpRequestMainThread
This one will be propagated from worker referrer policy (worker->GetReferrerPolicy()) in the case xhr is sent from worker
This way is how we solved the case global fetch 's referrer policy.
Thanks

Comment 6

2 years ago
Likely importScript() in workers is having the same problem which used incorrectly associated window document's referrer policy.
(In reply to Thomas Nguyen[:tnguyen] ni plz from comment #6)
> Likely importScript() in workers is having the same problem which used
> incorrectly associated window document's referrer policy.

Good catch!

Please be aware of some changes I hope to land shortly around worker referrer-policy:

  bug 1340652
  bug 1340654

That second bug, in particular, solves another issue where we incorrectly override the referrer-policy in the importScripts().  Just mentioning it in case you started looking at that as well.

Updated

2 years ago
Assignee: nobody → tnguyen

Updated

a year ago
Assignee: tnguyen → nobody
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.