1644970 - Pop-up blocker is over-aggressive

Status: RESOLVED FIXED

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

Description

[Thayne]

Attachment: screenshot.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

I've encountered this on two sites so far, where the pop-up blocker blocks legitimate new windows.

1. In lucidpress.com, if I try to create a new document from a template, the pop-up blocker blocks creating the new document
2. In docs.google.com, if I try to open a document from File->Open, while editing a document, it blocks opening the document.

Actual results:

The pop-up blocker prevents the web-app from opening a new window. Even though the new window is on the same domain, and the window is opened in response to a user-initiated event.

Expected results:

The window should have opened without triggering the pop-up blocker.

Comment 1

[Andrei Purice]

Hey there Thayne,

Firefox has a built-in pop up blocker which is by default enabled. You can easily fix this by going to about:preferences#privacy and by clicking the Exceptions, button which will open a modal, you can add what sites are allowed to use pop-ups and what not. Or just uncheck the "Block pop-up windows" and there will be no more confirmations for pop-ups in the future (since all pop-ups are allowed now).

Comment 2

[Thayne]

Andrei,

I'm aware of the pop-up blocker and the ability to add exception domains. But previously, firefox used heuristics to determine if the pop-up was the result of a user action. That doesn't seem to be working correctly anymore, which results in a worse user experience. As a developer of web applications, I'm also concerned that users will think the app is doing something bad, when they see this pop-up blocker while performing normal operations.

If this change in behaviour is intended, then it should be better communicated. In particular, users should be informed that it is OK to add exceptions to the pop-up blocker for sites they use. And app developers should be given guidance on how to avoid the pop-up blocker for opening new windows as a response to user actions.

Relatedly, the only options in the menu for the pop-up blocker are to add an exception for the domain, or to continue blocking. there isn't an option to navigate to this particular pop-up without unilaterally allowing all pop-ups for the domain.

Comment 3

[Andrei Purice]

Setting a component for this issue in order to get the dev team involved.
If you feel it's an incorrect one please feel free to change it to a more appropriate one.

Comment 4

[Twisted_Code]

Hi. Just wanted to add my two cents. I don't think my experience is enough to justify a separate bug ticket, but this might be useful. I discovered how aggressive and disruptive pop-up blocker can be, hence my being here now, when trying to edit TVTropes.
Reproduction steps for my situation:

1. Logged in
2. click "edit page" on any non-locked article. In my case, it was https://tvtropes.org/pmwiki/pmwiki.php/Main/ContemplateOurNavels
3. make some changes in the under
4. click the <button class="preview-html-button btn btn-success float-left"> element that appears below the editor, labeled "Preview".
   expected result:
   I get the preview.php page I requested from the server, since I obviously pressed a <button> that triggered the page that opened less than a second later, right?
   result:
   Instead of getting the preview.php page I expected, the page that gets sent back by the PHP server is intercepted, and if I choose to view the intercepted page, it's broken as you can see in the screenshot. My hypothesis for why this happens is that the PHP server only replies to each submission once in order to avoid hanging on to resources, so when the page is re-requested, it just gives a default response. While only a mild inconvenience for me, I can think of at least 2 situations where this could behavior from Firefox could be a real hassle: if you are unable to reproduce the event that triggered the pop up, or if you don't normally want pop-ups from the site that's sending them. In the former case, you might be SOL if, for instance, you lack the necessary data for the request; in the latter case, you'll have to go to wherever the pop-up whitelist is stored and remove the exception because but one-time option in the info bar will just break as described.

Comment 5

[Edgar Chen [:edgar]]

I could still reproduce this after bug 1733052.

Comment 6

[nicoleta.sibisan]

This also affects Microsoft 365.
STR

1. Launch Firefox
2. Go to https://office.live.com/start/Excel.aspx?omkt=en-US&auth=1&nf=1
3. Login with a valid account
4. Click on "Blank workbook" in the "Create new" section

Expected:

• a new workbook is created and opened

Actual:

• a new workbook is created, but it can not be opened automatically and an ambiguous message is displayed:
  “Unable to open your workbook
  We created your workbook, but are unable to open it. Please copy the following link and open it in a web browser.
  Correlation ID: bbaa4408-8e2d-4e97-8421-1054c0701e0c”

Additional notes

• The message says “copy the following link”, yet no link is present.
• Create new Blank document and Blank presentation don’t have this issue.

Comment 7

[Edgar Chen [:edgar]]

Now I can not reproduce the issue, I think it is fixed by setting dom.popup.experimental to true.
Let's close this for now. Feel free to reopen it or file a new bug if you encounter the issue again.