Using the correct principal to create channel for ServiceWorker NavigationPreload.
Categories
(Core :: DOM: Service Workers, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox99 | --- | fixed |
People
(Reporter: edenchuang, Assigned: edenchuang)
References
Details
Attachments
(2 files)
48 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta-
|
Details | Review |
48 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta-
|
Details | Review |
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 1•4 years ago
|
||
Currently using the pricinpal of InternalRequest to create the channel for NavigationPreload.
However, it is not a correct principal and makes NavigationPreload stop with channel security checking.
Instead of using the principal of InternalRequest, this patch uses the loadingPrincipal of InterceptedHttpChannel to create the channel.
Assignee | ||
Comment 2•4 years ago
|
||
Comment 4•4 years ago
|
||
Backed out for causing build bustages on Logging.h
Backout link : https://hg.mozilla.org/integration/autoland/rev/7dbedaab687b42d8a6ba8813ae486a744af0835b
Link to failure log : https://treeherder.mozilla.org/logviewer?job_id=367078071&repo=autoland&lineNumber=9374
Assignee | ||
Updated•4 years ago
|
Comment 7•4 years ago
|
||
Backed out 3 changesets (Bug 1750515, Bug 1753025) for causing wpt failures on idlharness.https.any.<...>.
Backout link
Push with failures
Failure Log
Assignee | ||
Updated•4 years ago
|
Comment 9•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/7692c70b812d
https://hg.mozilla.org/mozilla-central/rev/fb5026c2f822
Assignee | ||
Comment 10•3 years ago
|
||
Comment on attachment 9261807 [details]
Bug 1753025 - Using correct principal to create channel for NavigationPreload. r=#dom-worker-reviewers
Beta/Release Uplift Approval Request
- User impact if declined: If the user turns on NavigationPreload, it could make NavigationPreload fail due to using the wrong principal to create a channel.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Currently, NavigationPreload should be turned on manually. NavigationPreload fails would not cause ServiceWorker interception to fail, but it cannot gain the performance by NavigationPreload.
- String changes made/needed: No
Assignee | ||
Updated•3 years ago
|
Comment 11•3 years ago
|
||
Eden, could you explain how this is impacting our 98 release? I see this is blocking a feature that landed in 99 and is nightly only. Thanks
Assignee | ||
Comment 12•3 years ago
|
||
Pascal, thanks for ni. Yes, after discussion, we decide to make the feature be on with 98 release in default.
To make this feature be turned on, we need to uplift patches of this bug, and also bug 1750515 and bug 1754786. This is because we changed the test expectation result in these patches.
Patches in this bug have no dependency on other bugs for uplifting, so this is the first one to uplift. Then the patches on bug 1750515 and bug 1754786.
Comment 13•3 years ago
|
||
Comment on attachment 9261807 [details]
Bug 1753025 - Using correct principal to create channel for NavigationPreload. r=#dom-worker-reviewers
The feature is now targeting 99
Updated•3 years ago
|
Description
•