Zoom links from google calendar no longer auto-open with dom.delay.block_external_protocol_in_iframes.enabled=false
Categories
(Core :: DOM: Core & HTML, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox83 | --- | unaffected |
firefox84 | --- | unaffected |
firefox85 | --- | fixed |
People
(Reporter: emilio, Assigned: emilio)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(1 file)
Zoom still shows a button but still.
Assignee | ||
Comment 1•3 years ago
|
||
Per chat conversation the user interaction restriction should probably not apply to top
.
Assignee | ||
Comment 2•3 years ago
|
||
(Or same-origin-with-top)
Comment 3•3 years ago
|
||
Set release status flags based on info from the regressing bug 1679456
Assignee | ||
Comment 4•3 years ago
|
||
So this is a bit more complicated than that because we also don't want to allow top
DOSing us...
Johann has drafted a document on how we might want to deal with this... But basically either "always allow the first such navigation from top
" or "propagate user activation from opener", I think (I'm not sure about all the implications of the later).
Assignee | ||
Comment 5•3 years ago
|
||
So I took a look at what Chrome does here, just to see how compatible such a solution would be, and because its blocking mechanism claims to be based on user interaction but it's not.
Chrome takes the user activation state here and doesn't consume it.
It seems they do nothing with the has_user_interaction
bit, actually. Instead, the policy seems to be based on a global bool in the parent process, which gets reset whenever the user interacts with any website.
So basically their policy is "allow by default, but spawning one dialog prevents any other dialog from any other website from spawning until the user has interacted with any website". Which is a pretty weird policy IMO...
This is also experimentally how it works. If you have two tabs, one continually opening external protocols like:
<!doctype html>
<body>
<script>
(function f() {
let frame = document.createElement("iframe");
frame.src = "irc://foo";
document.body.appendChild(frame);
setTimeout(f, 500);
}());
</script>
Then:
- The page will successfully spawn the first dialog.
- The page will stop spawning dialogs because you haven't interacted with the content anymore.
- But if you switch tabs and click on the other tab, then switch back, the dialog starts appearing again.
Odd.
Assignee | ||
Comment 6•3 years ago
|
||
Only for top windows because for nested iframes they could get around
this without being noticed by reloading themselves which is not great.
Assignee | ||
Updated•3 years ago
|
Updated•3 years ago
|
Comment 7•3 years ago
|
||
Looks like that pref is nightly only.
Updated•3 years ago
|
Updated•3 years ago
|
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b0dedb91a7fc Grant a single iframe without user interaction to top windows. r=smaug,johannh
Comment 9•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Description
•