Closed Bug 1517703 Opened 6 years ago Closed 6 years ago

Implement Referrer class encapsulates full referrer and referrer policy

Categories

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

enhancement

Tracking

()

RESOLVED FIXED
mozilla67
Tracking Status
firefox67 --- fixed

People

(Reporter: tnguyen, Assigned: tnguyen)

References

(Blocks 1 open bug)

Details

(Whiteboard: [domsecurity-active])

Attachments

(2 files, 1 obsolete file)

No description provided.
Assignee: nobody → tnguyen
Priority: -- → P2
Status: NEW → ASSIGNED
Whiteboard: [domsecurity-active]
Attachment #9036920 - Attachment description: 1 - Bug-1517703-Implement-ReferrerInfo-class → 1 - Bug-1517703 Implement ReferrerInfo class and use it in DocshellLoadState
Attachment #9036920 - Attachment is obsolete: true

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

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

Flags: needinfo?(gijskruitbosch+bugs)

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

Flags: needinfo?(gijskruitbosch+bugs)
Attachment #9039734 - Attachment description: Bug 1517703 - Part 2 - Use ReferrerInfo in loadURI from js → Bug 1517703 - Part 2 - Use ReferrerInfo in loadURIOptions from js
Attachment #9039734 - Attachment description: Bug 1517703 - Part 2 - Use ReferrerInfo in loadURIOptions from js → Bug 1517703 - Part 2 - Use ReferrerInfo in loadURI from js
Attachment #9039734 - Attachment description: Bug 1517703 - Part 2 - Use ReferrerInfo in loadURI from js → Bug 1517703 - Part 2 - Use ReferrerInfo in loadURIOptions from js
Pushed by tnguyen@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/64c8b805491a Part 1 - Implement ReferrerInfo class r=smaug
Pushed by tnguyen@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/586348ccba9b Part 2 - Use ReferrerInfo in loadURIOptions from js r=Gijs
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
Depends on: 1545255
Depends on: 1549732
Regressions: 1558917
Regressions: 1556827
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: