Remove overloading of mStorageAccessPermissionGranted on Window objects
Categories
(Core :: Privacy: Anti-Tracking, enhancement)
Tracking
()
Tracking | Status | |
---|---|---|
firefox103 | --- | fixed |
People
(Reporter: bvandersloot, Assigned: bvandersloot)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
This variable caches a combination of the result of ShouldAllowAccessFor and the result of requesting storage access. We should disentangle these.
Assignee | ||
Comment 1•3 years ago
|
||
mStorageAccessPermissionGranted was initialized to ShouldAllowAccessFor(...).
This had logic that has nothing to do with this the permission being granted.
A few bugs with my helpers were covered up by this default value, so I fixed the helpers in the same patch here.
This also required adding a new helper to the RejectForeignAllowList and exposing it to the Document.cpp file.
I'm not enthused about making that available, but we don't have a good component boundary for now, so I don't hate it.
Ideally the implementation of the rSA and hSA funcitons (and the like) would be in our component, but that is outside of this change's scope.
Updated•3 years ago
|
Assignee | ||
Comment 2•3 years ago
|
||
With the use of mStorageAccessPermissionGranted reduced to a single meaning, it turns out to be entirely redundant with the variable on the inner window.
Depends on D147867
Comment 5•3 years ago
|
||
Backed out 5 changesets (Bug 1765313, Bug 1770403) for causing bc failures on browser_storageAccessPrivilegeAPI.js.
Backout link
Push with failures <--> bc3
Failure Log
Assignee | ||
Comment 6•3 years ago
|
||
The fix for /storage-access-api/requestStorageAccess.sub.window.html
caused this failure. I edited D147867 to resolve this.
I also re-tested locally, both browser chrome tests and wpt.
Comment 8•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/9e5ed810427c
https://hg.mozilla.org/mozilla-central/rev/1723828ce4bb
Description
•