1894244 - Popup blocker is too strict when opening new windows

Status: NEW

(Core :: DOM: Window and Location, defect, P3)

Description

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

Example: scroll down https://www.forumforthefuture.org/ and try to subscribe to a new letter. The same issue happens on other sites too

Comment 1

[Oliver Medhurst [:canadahonk]]

I can reproduce. There is definitely a user activation when clicked which is not consumed (checked with navigator.userActivation.isActive). I haven't looked into it in detail yet, but my potential guesses at what is going wrong:

• Popup blocker is just ignoring user activation/not trying to use it
• User activation is too late (for the popup blocker)

In terms of user activation behavior in this example, Gecko vs Chromium from an observer:

Gecko:

1. Click subscribe button
2. User activation occurs
3. New window is blocked
4. Transient user activation remains until 5s timeout

Chromium:

1. Click subscribe button
2. User activation occurs
3. New window is opened
4. Transient user activation is gone as soon as new window is opened

NIing myself for further investigation as this seems like a common bug across various sites.

Comment 2

[Edgar Chen [:edgar]]

(In reply to Oliver Medhurst [:canadahonk] from comment #1)

• Popup blocker is just ignoring user activation/not trying to use it

Yes, I think it is the case. I did a quick check, the script calls window.open() in load event handler for script element. load event isn't in the allowed event list, so we push openBlocked state to the PopupState stack which will block popup without checking user activation.

I think perhaps we could make this case also fall back to check user activation, like what we does for openAbused state which is the default popup state.

Comment 3

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

Why does this bloc bug 1917381, which seems to be a regression from something?

Comment 4

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

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

Why does this bloc bug 1917381, which seems to be a regression from something?

Right, this may not be right. "See also" should have been a better connection between this and bug 1917381.
I set that dependency while recalling a similar old bug 1601479.