1917381 - Gmail pop-ups are blocked even though it is on the list of allowed websites with pop-ups

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Vicky Chin [:vchin]]

Clicking on links in gmail is blocked even though it is already listed on the list of sites to allow pop-ups. The preferences dialog that shows up doesn't have an option to allow pop-ups. (See Attachment)

I haven't made any recent changes to pop-up permissions. I'm on Firefox Nightly 131.0a1 (2024-08-31) MacOS 14.6.1.

Comment 1

[Vicky Chin [:vchin]]

Attachment: Pop ups are blocked even though it's on the allow list.

Comment 2

[Vicky Chin [:vchin]]

Attachment: mail.google.com is on allow list

Comment 3

[Vicky Chin [:vchin]]

Updating to a newer Nightly 132.0a1 (2024-09-02) seems to have fixed the problem.
Worth noting that in that state, even removing mail.google.com in the Allow list and giving permission again, pop-ups were still blocked.

Comment 4

[Mike Conley (:mconley) (:⚙️)]

Hm. Sounds like maybe a hiccup in our permissions mechanisms? Our popup blocking code has been fairly stable, and I'm not aware of any active work in that area that might have affected this.

Hey pbz, can you think of anything permissions-related that might have affected this? Mainly asking for completeness sake. Considering comment 3, we might just want to close this out as INCOMPLETE later this week.

Comment 5

[Paul Zühlcke [:pbz]]

I was just able to reproduce. I'm looking into it.

Comment 6

[Paul Zühlcke [:pbz]]

The UI sees the "popup" permission. That's why it rightfully offers to block popups. The bug seems to be somewhere in the backend. Using the Browser Toolbox I was able to trace it all the way back to the DOMPopupBlocked event which gets dispatched here: https://searchfox.org/mozilla-central/rev/26a98a7ba56f315df146512c43449412f0592942/dom/base/nsGlobalWindowOuter.cpp#5493
We need to check why Gecko thinks it needs to block the popup even though there is a "popup" permission for the GMail.

I was curious if there was a bug where the content process doesn't see the permission. I set a breakpoint in PopupBlockingChild.sys.mjs and executed Services.perms.testPermissionFromPrincipal(this.document.nodePrincipal, "popup") == Services.perms.ALLOW_ACTION which returns true. That means the permission is properly propagated to the content process.

I'm moving it to DOM for now since this is not a UI bug.

Comment 7

[Hsin-Yi Tsai (she/her) [:hsinyi]]

I'm going to try if flipping the preference dom.popup.experimental makes any difference.

Comment 8

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Hsin-Yi Tsai (she/her) [:hsinyi] from comment #7)

I'm going to try if flipping the preference dom.popup.experimental makes any difference.

I didn't seem to encounter this issue, whether I flip dom.popup.experimental or not.

Olli, does what comment 6 described match the behavior that we expect to be resolved by bug 1894244? Or is comment 6 pointing to another underlying problem?

Comment 9

[Olli Pettay [:smaug][[e-mail]](vacation until Nov 16)]

vchin, so was this a regression which doesn't happen in the current Nightly? Does it happen still on older Nightly?
We really need some regression range here, from someone who can reproduce the issue.

Flipping dom.popup.experimental might help here, but we need to understand why the behavior has changed here. dom.popup.experimental has been disabled all the time.

Comment 10

[Andrew McCreight [:mccr8]]

Two other people on MoCo Slack have also experienced this issue.

Comment 11

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi Raul, wanted to bring this to your attention radar, and see if you can help to get a regression window. Thanks.

Comment 12

[Paul Zühlcke [:pbz]]

If somebody manages to reproduce again, it would be good to attach a debugger and see if this permission check gets called and whether it returns the set permission exception: https://searchfox.org/mozilla-central/rev/1b90936792b2c71ef931cb1b8d6baff9d825592e/dom/base/PopupBlocker.cpp#125
It's also possible there is a bug in how this permission flag gets propagated / checked. I'm not very familiar with our popup blocker code.

Comment 13

[Olli Pettay [:smaug][[e-mail]](vacation until Nov 16)]

Anyone who can reproduce this should try to find the regression range - assuming there is a regression range.

Comment 14

[Vicky Chin [:vchin]]

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #9)

vchin, so was this a regression which doesn't happen in the current Nightly? Does it happen still on older Nightly?
We really need some regression range here, from someone who can reproduce the issue.

Flipping dom.popup.experimental might help here, but we need to understand why the behavior has changed here. dom.popup.experimental has been disabled all the time.

After I updated to a newer Nightly and thus restarted, the problem went away. Based on other comments on slack, it seems it goes away on restart so my hunch is that it's intermittent. I was first notified about this being an issue on Aug 29 (didn't experience it myself until I reported the bug) but I wonder if it's related to bug 1754005.

Comment 15

[Raul Bucata]

I'll gladly look for a regression range, but I am not able to trigger pop-ups from mail.google.com. Vicky, are there any steps I need to take in order to trigger pop-ups from Gmail?

Comment 16

[Vicky Chin [:vchin]]

It should trigger when you try to print.

Comment 17

[Paul Zühlcke [:pbz]]

(In reply to Vicky Chin [:vchin] from comment #14)

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #9)

vchin, so was this a regression which doesn't happen in the current Nightly? Does it happen still on older Nightly?
We really need some regression range here, from someone who can reproduce the issue.

Flipping dom.popup.experimental might help here, but we need to understand why the behavior has changed here. dom.popup.experimental has been disabled all the time.

After I updated to a newer Nightly and thus restarted, the problem went away. Based on other comments on slack, it seems it goes away on restart so my hunch is that it's intermittent. I was first notified about this being an issue on Aug 29 (didn't experience it myself until I reported the bug) but I wonder if it's related to bug 1754005.

I don't think bug 1754005 is related. The popup blocker permissions are persistent, not temporary. Also the permission check happens solely on the backend which doesn't even have access to temporary permissions. In my initial investigation (comment 6) I did see the permission being set correctly.

Comment 18

[Olli Pettay [:smaug][[e-mail]](vacation until Nov 16)]

FWIW, I've tried to reproduce this using a bit older builds, no luck so far. All the builds just seem to work. I never get popup blocker.

Comment 19

[Neha Kochar [:neha]]

https://bugzilla.mozilla.org/show_bug.cgi?id=1896672 was fixed in Fx130 - could this be related?
Ignore this - it's already referenced above by Hsin-Yi - the pref dom.popup.experimental

Comment 20

[Neha Kochar [:neha]]

never mind, that is the

Comment 21

[Vicky Chin [:vchin]]

I just ran into this issue in Nightly 132.0a1 2024-09-13 build. I've been using it all day with no issues and the pop-up issue just resurfaced. I'm going to keep my session open, let me know how I can help debug.

What doesn't work:

• opening links to google suite documents e.g. slides, sheets, etc.
• opening links from bugzilla emails also doesn't work if I click on links to the bug number

Interestingly if I click on a link with an explicit URL from a needinfo email, it opens fine. e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1917381
I have containers running and my personal gmail container has no issues opening links and no popups are blocked.

Comment 22

[Olli Pettay [:smaug][[e-mail]](vacation until Nov 16)]

Not about this regression, but could you try setting dom.popup.experimental to true in about:config. No need to restart. Does it change the behavior? (I'm planning to enable that pref soon by default, but I'd rather not do it before we understand what is going wrong with this bug.)

Comment 23

[Raul Bucata]

I could not reproduce the issue, even with the build stated in comment 21. After allowing Gmail as an exception, pop-ups from the page are no longer blocked.

Tested with:

Browser / Version: Firefox Release 131.0 (64-bit)/ Firefox Nightly 133.0a1 (2024-10-01) (64-bit)
Operating System: Windows 10 PRO x64
Operating System: Mac Ventura 13.1

Comment 24

[Paul Zühlcke [:pbz]]

It seems like there are two failures here:

1. Google doing something that trips our popup blocker. Normal link clicks shouldn't - perhaps they're doing something via JS?
2. Our popup blocker not respecting the exception permission which is set.

We could make a build that adds logging to suspicious places and see if somebody runs into the issue with that.
Additionally could make the build always trip the popup blocker on GMail, to see if at some point the exception permission fails.
If this is really a two stage failure eliminating the first stage could make this failure more frequent

Comment 25

[Vicky Chin [:vchin]]

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #22)

Not about this regression, but could you try setting dom.popup.experimental to true in about:config. No need to restart. Does it change the behavior? (I'm planning to enable that pref soon by default, but I'd rather not do it before we understand what is going wrong with this bug.)

It doesn't change the behaviour.

Comment 26

[Olli Pettay [:smaug][[e-mail]](vacation until Nov 16)]

Raul, "allowing Gmail as an exception"? When do you get that? I never need to allow popups with Gmail (new or old FF profile)

Comment 27

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #26)

Raul, "allowing Gmail as an exception"? When do you get that? I never need to allow popups with Gmail (new or old FF profile)

Olli, I get that when I click "In new window" icon in the upper right corner.
Flipping the preference dom.popup.experimental changes the behavior for me. When the preference is set to true, even if there is no allow exception for gmail in the about:preferences, I don't get a prompt saying the popup is blocked.

Comment 28

[Olli Pettay [:smaug][[e-mail]](vacation until Nov 16)]

Vicky, another pref to test :) Set dom.disable_open_during_load to false, shouldn't need restart.
(Just trying to understand in which start the WindowContext is)

Comment 29

[Raul Bucata]

Olli, I also get the pop-up when trying to print something from an email, using their "Print" button

Comment 30

[Olli Pettay [:smaug][[e-mail]](vacation until Nov 16)]

I think I found it.

Comment 31

[Olli Pettay [:smaug][[e-mail]](vacation until Nov 16)]

Attachment: Bug 1917381 - disable the ancient dom.popup_maximum pref by default, r=#dom-core

Comment 32

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8537b5e45cf0
disable the ancient dom.popup_maximum pref by default, r=emilio

Comment 33

[Atila Butkovits]

Backed out for causing failures at 1419902.html.

Backout link: https://hg.mozilla.org/integration/autoland/rev/3de4b865f57b9d08f4b0c5bd9f4a28f347f4ab6c

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=8537b5e45cf02614b612b954a08f5bd5ab302254&selectedTaskRun=KzJiAn1NSGazm8thiRH-Cw.0

Failure log: https://treeherder.mozilla.org/logviewer?job_id=476706732&repo=autoland&lineNumber=18818

Comment 34

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/92bbe571d188
disable the ancient dom.popup_maximum pref by default, r=emilio

Comment 35

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/92bbe571d188

Comment 36

[Nick Alexander :nalexander [he/him]]

Folks, I witnessed this with Nightly 20240923142214. Unfortunately I'm on macOS, so I can’t attach a debugger due to https://firefox-source-docs.mozilla.org/contributing/debugging/debugging_on_macos.html#official-builds. However, when I set dom.popup_maximum=-1 by hand, I was no longer blocked. I think that counts as verifying the fix, and I'll clear the pending NIs since we believe this has been addressed.