Remove about:config preference that enables the old "cookieBehaviors override on top level extension page" in the AntiTracking internals
Categories
(WebExtensions :: General, task, P1)
Tracking
(firefox71 fixed)
Tracking | Status | |
---|---|---|
firefox71 | --- | fixed |
People
(Reporter: rpl, Assigned: rpl)
References
Details
Attachments
(1 file)
As part of Bug 1525917 we are going to apply changes to the AntiTracking internals to ensure that the "cookiesBehavior overriding" applied for the extension pages is not extended to third party webpages (e.g. a webpage embedded as a subframe of an extension page should respect the cookieBehavior, and cookies received for a XHR or fetch request directed to a web url from an extension page should also respect the currently set cookieBehavior).
Despite the additional tests we are going to add in the same bug (to increase the coverage of the scenarios we have already identified), there is still a chance that the above ("backward incompatible") changes could introduce some regressions that we may have missed in Bug 1525917, and so we are going to add a new about:config preference (currently named "extensions.cookiesBehavior.overrideOnTopLevel"
) which allows to restore the old behavior (intended to be used only in case we notice a regression that we have to fix before we can allow the changes from Bug 1525917 to reach a release version).
The goal of this issue is to remove the above preference as soon as we have released the new behavior and we don't need to restore the old behavior anymore.
The pref removal is going to require at least the following changes:
- Remove the pref definition from
modules/libpref/init/StaticPrefList.h
- Remove any usage of the pref from
toolkit/components/antitracking/AntiTrackingCommon.cp
(and the related legacy behavior locked behind the pref) - Remove the pref from
toolkit/components/extensions/test/xpcshell/test_ext_cookieBehaviors.js
(and remove the test code that handles the scenario where the pref is set back to true)
Assignee | ||
Updated•6 years ago
|
Updated•6 years ago
|
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 2•5 years ago
|
||
Comment 4•5 years ago
|
||
bugherder |
Comment 5•5 years ago
|
||
Hello,
Will this fix require manual validation? If yes, please provide some steps to reproduce in order to correctly test it and also, please set the "qe-verify+" flag. Otherwise, could the "qe-verify-" flag be added? Thanks!
Assignee | ||
Comment 6•5 years ago
|
||
I'm marking this qe-verify-, because the change is covered by the automated tests and the part removed was related to a "fallback behavior" that was turned off by default (and it has never been turned on over the three release that were supporting the "fallback" preference).
Description
•