document.requestStorageAccess error thrown even from static (plaintext) iframe content
Categories
(Core :: Privacy: Anti-Tracking, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr91 | --- | unaffected |
| firefox-esr102 | --- | wontfix |
| firefox102 | --- | wontfix |
| firefox103 | --- | wontfix |
| firefox104 | --- | verified |
People
(Reporter: myf, Assigned: bvandersloot)
References
(Regression)
Details
(Keywords: regression)
Attachments
(2 files)
Firefox Nightly window with with focused plaintext frame inside the test page and error visible in the Console.
Interacting with any(?) iframe content produces
document.requestStorageAccess() may not be called on a document with an opaque origin, such as a sandboxed iframe without allow-same-origin in its sandbox attribute.
error visible in dev-tools console.
Test:
data:text/html,<!doctype html><iframe src="data:text/plain,interact here"></iframe>
Click fires this exception twice, non-modifier key press once. As seen, there is no JavaScript requesting anything involved. Same outcome when loaded as real file from secure origin.
Observed in current newest stable v102, Developer Edition (v103.0b2 20220628190840) and v104 Nightly. Not reproducible in last v101.
|
||
Comment 1•2 years ago
|
||
The severity field is not set for this bug.
:dveditz, could you have a look please?
For more information, please visit auto_nag documentation.
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
|
||
Comment 2•2 years ago
|
||
mozregression points to Bug 1765309. Ben, could you please take a look? Thanks!
|
|
||
Comment 3•2 years ago
|
||
Here is the pushlog from mozregression: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c1ef18d0a27ec4c2736cbb2c8ae8b061bd728f2e&tochange=3b0030f76f1ee69138d29f114d5221f21c55e7e5
It's a bit wide because some builds crashed on me.
|
|
||
Comment 4•2 years ago
|
||
Correcting tracking flags.
|
|
||
Updated•2 years ago
|
|
||
Updated•2 years ago
|
|
Assignee | |
Comment 5•2 years ago
|
||
|
||
Updated•2 years ago
|
|
|
Assignee | |
Comment 6•2 years ago
|
||
In combining code paths for hasStorageAccess and requestStorageAccess, I incidentally included console logs for hasStorageAccess calls. This was exacerbated by using the hasStorageAccess code paths to check if an iframe should get the storageAccessAPI permission on user interaction. This resulted in the above bug. There is a related but slightly different behavior that is probably also observed by the reporter: the console may have also reported document.requestStorageAccess() may not be called in a sandboxed iframe without allow-storage-access-by-user-activation in its sandbox attribute. Both cases are to be fixed by https://phabricator.services.mozilla.com/D152171
|
|
Assignee | |
Updated•2 years ago
|
|
|
Assignee | |
Updated•2 years ago
|
Pushed by bvandersloot@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/91af4fe4bfab document.requestStorageAccess error thrown even from static (plaintext) iframe content, r=pbz
|
||
Comment 8•2 years ago
|
||
Could you review the severity on this?
Is there any functional regression on this that would need a 103 uplift consideration or could this patch ride the trains with 104?
|
||
Comment 9•2 years ago
|
||
| bugherder | ||
|
||
Comment 10•2 years ago
|
||
It doesn't really break the functionality of Storage Access API but it causes incorrect console messages. I think we should consider uplifting this bug if possible given that this confuses developers.
|
|
||
Comment 11•2 years ago
|
||
The patch landed in nightly and beta is affected.
:bvandersloot, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox103towontfix.
For more information, please visit auto_nag documentation.
|
|
||
Comment 12•2 years ago
|
||
Setting 103 to fix-optional. 103 is now in RC.
When you are confident in the fix, if I get a release uplift request I can consider it as a ride-along in an RC respin or dot release for 103.
|
|
Assignee | |
Comment 13•2 years ago
|
||
While requesting an uplift I went to verify this patch works in Nightly. When testing I found that there are tab crashes with iframes in today's Nightly release. I'm going to try to see if this patch is causing those crashes or if it is unrelated.
Leaving the needinfo.
|
|
||
Comment 14•2 years ago
|
||
I don't think this needs to be in 103. Seems to risky to do an uplift at this point. The issue exists since 102 already and is only developer-facing.
|
Reporter | |
Comment 15•2 years ago
|
||
If I can speak for developers, I agree there is no need to rush with uplifting. From developer's perspective it is really just a strange message in the console that appears on "gesture". When concerned, searching for it's text should bring them to this issue and dispel their worries.
|
|
Assignee | |
Comment 16•2 years ago
|
||
Crashes were unrelated.
We discussed this and think :pbz is correct. A RC uplift for a developer-facing feature is too high risk.
Marking as wontfix in 103.
|
||
Updated•2 years ago
|
|
||
Comment 17•2 years ago
|
||
Reproduced the issue with Firefox 104.0a1 (2022-06-29) on Windows 10x64.
The issue is verified fixed with Firefox 104.0b4 (20220731190208) on Windows 10x64, macOS 11 and Ubuntu 20. The error is no longer displayed inside the web console after interacting with the field from the comment 0 test case.
|
||
Comment 18•2 years ago
|
||
This doesn't graft cleanly to ESR102 and it seems edge case enough that we can probably live with this bug there. If you strongly disagree, feel free to attach a rebased patch and request uplift approval.
Description
•