1686097 - If something blocks a popup from an iframe, and that iframe is removed, we hide the popup blocking UI.

Status: NEW

(Toolkit :: General, defect, P3)

Description

[Emilio Cobos Álvarez (:emilio)]

See bug 1685056 for an instance of this. Bug 1685056 comment 10 and the reply for some context... But basically, we're keying popups per-window, which means that if a frame goes away so does the popup.

Test-case independent of bug 1685056 incoming.

Comment 1

[Emilio Cobos Álvarez (:emilio)]

Attachment: Test-case 1 (without waiting for load, without removing the frame)

Since the initial about:blank window where we call window.open() is replaced, we remove the actor and hide the UI, no need to even remove or navigate the iframe.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Attachment: Test-case 2

Removing the iframe.remove() call properly keeps the popup blocker UI.

Comment 3

[:Gijs (he/him)]

Sorry for being dense, but I'm struggling to distinguish the summaries of this and bug 1685056. That is, with that bug fixed, what is still left to do here?

Comment 4

[Emilio Cobos Álvarez (:emilio)]

That bug was fixed by restoring to the previous behavior (not blocking the popup). But if we block the popup (like the attached test-case), we still eagerly remove the popup blocker bar.

Comment 5

[Luca Greco [:rpl] [:luca] [:lgreco]]

Hi Emilio,
during Toolkit/Firefox::General triage we did agreed on moving this issue in the same bugzilla component where bug 1685056 is, but feel free to move it in a more appropriate component if it doesn't belong there.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

This is a toolkit bug. I put it in Toolkit :: General because that's the component for toolkit/actors/PopupBlockingParent.jsm, which is where this would have to be fixed. The issue is that PopupBlockingParent keeps the popup blocked tab per window, not per tab.

Comment 7

[Micah [:mtigley] (she/her)]

Gijs, we're not too sure who the owner for PopupBlocking in the toolkit bug would be. Would you be able to set a priority and severity for this issue? Or point it to someone who can?

Comment 8

[:Gijs (he/him)]

(In reply to Micah Tigley [:mtigley] from comment #7)

Gijs, we're not too sure who the owner for PopupBlocking in the toolkit bug would be. Would you be able to set a priority and severity for this issue? Or point it to someone who can?

Unfortunately there is no strong owner for popup blocking, but I can try and move this forward a bit more...

(In reply to Emilio Cobos Álvarez (:emilio) from comment #6)

The issue is that PopupBlockingParent keeps the popup blocked tab per window, not per tab.

So, this is a bit interesting, because we also do not currently share the full URI with the parent process, because that has IPC data size issues (cf. bug 1273685). Also, the original window.open call happened on some frame X, and the effect will not be the same if we run it against some other (ancestor) frame Y. Like, should we just open it with the "wrong" referrer and opener relationship?

Are there obvious solutions to this that I'm missing?

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Not sure, maybe not. It might be interesting to dig into what do other browsers do. Chrome seems to be able to open the popup even if the frame is gone... Though maybe it doesn't get the right opener and such.