1517703 - Implement Referrer class encapsulates full referrer and referrer policy

Status: RESOLVED FIXED

(Core :: DOM: Security, enhancement, P2)

Comment 2

[Thomas Nguyen (:tnguyen)]

Attachment: 1 - Bug-1517703 Implement ReferrerInfo class and use it in DocshellLoadState

Comment 3

[Thomas Nguyen (:tnguyen)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=28a3415b55d2ab8bffc6ebee3d414dc6a82b5d86

Comment 4

[Thomas Nguyen (:tnguyen)]

Attachment: Bug 1517703 - Part 2 - Use ReferrerInfo in loadURIOptions from js

Comment 5

[Thomas Nguyen (:tnguyen)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=a116065559343bbd86690034e28bbf09fbe7ea96

Comment 6

[Thomas Nguyen (:tnguyen)]

Attachment: Bug 1517703 - Part 1 - Implement ReferrerInfo class

The class contains original full referrer and referrer policy will be
applied to the referrer.

Comment 7

[Christoph Kerschbaumer [:ckerschb]]

Hey Gijs, I was wondering if you are willing to negotiate a compromise for this bug. In general I completely agree to your comment (which I am pasting from phab here for the reference:)

We should be changing all the things that pass referrer and referrerPolicy separately to pass referrerInfo, instead of only doing so for individual loadURI calls and thus leaving large parts of the frontend codebase messy and out of sync with the actual implementation.

Some background, the changeset that Thomas is working is growing to be massive [1] - I am worried that rebasing and maintaining those patches is going to become a cumbersome and time consuming task. Further, I also don't want the frontend code to be messy and left alone in a half baked state - Thomas is dedicated to work on referrer policy setup change the entire quarter.

Here is my suggestion:
a) We take all the backend bits from [1]; adding the new referrerinfo class, update docshell and docshelloatsate. That way we would have the backend bits landed.
b) We update LoadURIOptions.webidl and replace referrer and referrerpolicy with referrerinfo
c) We update only the callsites that create a loadURIOptions argument in this first iteration to pass a referrerinfo (basically all the callsites we touched within Bug 1513241.
d) We file follow ups and actually implement those to push the creation of the referrerinfo object further towards the actual creation time of the referrer.

That way we have smaller incremental changes that actually seem to be manageable to me.

Would you agree to that? If so, then Thomas would get such a changeset ready for review.

[1] https://hg.mozilla.org/try/rev/f1c97f45397aaf7991fa8ddb38a6eace54587edf

Comment 8

[:Gijs (he/him)]

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #7)

Would you agree to that? If so, then Thomas would get such a changeset ready for review.

Sure, as long as we end up in a state where this gets done, ideally within a cycle.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/64c8b805491a
Part 1 - Implement ReferrerInfo class r=smaug

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/586348ccba9b
Part 2 - Use ReferrerInfo in loadURIOptions from js r=Gijs

Comment 11

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/64c8b805491a
https://hg.mozilla.org/mozilla-central/rev/586348ccba9b