Opening a new issue from bug 1545273 because due to comment 18 this is a separate one. Just a reminder that we can use the same STR.

Affected versions

• Firefox 68.0a1 (20190502220333)

Affected platforms

• Windows 10 x64
• Ubuntu 18.04 x64
• macOS 10.14

Steps to reproduce

1. Open Firefox and go to https://www.politico.com/magazine/story/2019/04/08/alexandria-ocasio-cortez-new-york-226578.
2. Click “Show Comments”.
3. In the comment box enter "Hello".
4. Click "Log In to Post".

Expected result

• A Facebook login popup is created, allowing you to log in.

Actual result

• No pop-up is created.

Additional Notes

• Attached a screen recording with the issue.
• The pop-up window appears only when “Log in to Post” button is selected again or "Allow pop-ups for www.politico.com" is selected from the "Options" (yellow bar).

From https://bugzilla.mozilla.org/show_bug.cgi?id=1545273#c18:

Here is what is happening:

1. facebook's iframe calls document.requestStorageAccess(). It obtains a Promise, unresolved yet.
2. The user clicks on the link.
3. the promise is resolved
4. facebook's iframe does window.open().
5. There are no user-interaction, and the popup is denied.

It seems that we need to propagate the popup-blocking state somehow. Definitely, this is a separate bug.

My questions are:

• In step 3, why is the promise being resolved?
• Is FB's code calling the storage access API first and then opening the popup? Can you maybe paste some code snippet to help us understand the flow better?

Thanks!

The code should be something like this:

elm.onclick = _ => {
// step 1
new Promise(resolve => { ... something(resolve); })
.then(_ => {
// step 2
return document.requestStorageAccess();
})
.then(_ => {
// step 3
somethingElse();
})
.then(_ => {
// step 4
window.open(url);
});
}

User-interaction is correctly propagated through the chain, but in step 4, we don't inform PopupBlocker that we had a user-interaction propagation and the window.open() is aborted.

This looks to be fixed now.