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. Could there perhaps be a a bug where the content process doesn't see the permission? I'm moving it to DOM for now since this is not a UI bug.
Bug 1917381 Comment 6 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
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.