Closed Bug 1680721 Opened 3 years ago Closed 3 years ago

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)

defect

Tracking

()

RESOLVED FIXED
85 Branch
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.

Per chat conversation the user interaction restriction should probably not apply to top.

(Or same-origin-with-top)

Set release status flags based on info from the regressing bug 1679456

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).

Flags: needinfo?(emilio)

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.

Only for top windows because for nested iframes they could get around
this without being noticed by reloading themselves which is not great.

Flags: needinfo?(emilio)

Looks like that pref is nightly only.

Severity: -- → S3
Status: NEW → ASSIGNED
Type: defect → enhancement
Priority: -- → P2
Type: enhancement → defect
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
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 85 Branch
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: