1292701 - Autoclose popups shouldn't close when they open a modal dialog (e.g., file picker)

Status: NEW

(Core :: XUL, defect)

Description

[conrad.foucher]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36

Steps to reproduce:

Created a webExtension with a popup browser_action. In the popup html is an <input type="file" ...> tag, used to allow a user to upload a file into the extension.


Actual results:

When the user clicks the file select button the file select window is displayed. When the user clicks into the file select window the popup is closed. This renders severs the connection/link between the file select window and the code running in the popup page, resulting in nothing happening when the user selects a file.


Expected results:

The popup page should remain open while the user is selecting a file in the file select window.

Comment 2

[merijn.de.jonge]

Hi,

Is there any progress on this or any workaround?
Seems like a showstopper for many plugins (including mine :-( ).

Thanks for any info.

Merijn

Comment 3

[:Gijs (away/busy until Mar 10)]

I'm not sure I know how to fix this (or that, even though I moved this, this is the right component), as there are a lot of moving parts between the add-on and the dialog appearing. Neil or Kris, do you have any ideas?

Comment 4

[Neil Deakin]

No, the popup should close when you open another window. If you want a popup that isn't transient, then use noautohide.

Comment 5

[:Gijs (away/busy until Mar 10)]

(In reply to Neil Deakin from comment #4)
> No, the popup should close when you open another window. If you want a popup
> that isn't transient, then use noautohide.

I think we want it to be transient for everything else, but web extensions load content in iframes in the popup, so if those iframes have a file input (the only way to get the user to give those popups access to a file, given webextension limitations), opening the 'open file' dialog then closes the popup, which kills the anchor of the file input and its document, which means the code in the frame never gets the file. It would be a nuisance to have to workaround this limitation in our frontend code by adding noautohide but reimplementing all the 'transientness' for all the other cases in JS (ie, if the user focuses somewhere outside the popup, close the popup, if the window loses focus, close the popup, etc. - I'm sure I've forgotten some of this). Given that the open file dialogs are modal, I wouldn't have thought it would be a problem to keep the popup open for this? Is it just as hard to make an exception for modal dialogs from the C++ popup code?

Related: can someone attach a test add-on? Does the behaviour work correctly in Chrome?

Comment 6

[Neil Deakin]

Possibly, but it would require work to determine when the modal dialog has appeared so that we can clear the mouse/keyboard capturing state, then when the modal dialog has disappeared, reenable it again. The popup would also appear on top of the modal dialog on Linux (assuming you haven't changed the level)

Is it just the <html:input type="file"> file picker that is the issue here? The duplicate bug 1312223 doesn't mention that, nor does it mention that the window being opened is a modal dialog at all.

Comment 7

[Kris Maglione [:kmag]]

I think we should arguably handle this case. The file dialogs are modal for a window that's a child of the popup element, so arguably the popup still has focus in this case.

(In reply to :Gijs from comment #5)
> Related: can someone attach a test add-on? Does the behaviour work correctly
> in Chrome?

My understanding is that it does, but Chrome's auto-hide popups work differently from ours, and apparently they stay open when another browser window has focus, but close when something else in the same window gets focus.

(In reply to Neil Deakin from comment #6)
> Is it just the <html:input type="file"> file picker that is the issue here?

In this particular case, yes. But it would also be an issue for other modal popups, like alerts (which I don't care about), and window.open with "modal" (which shouldn't be supported here, anyway).

> The duplicate bug 1312223 doesn't mention that, nor does it mention that the
> window being opened is a modal dialog at all.

I was assuming that bug was talking about a modal window, but thinking more about it, that's probably not possible. I suppose keeping the popup open while a non-modal child window is focused might also make sense, but is a different bug.

Comment 8

[merijn.de.jonge]

Bug 1312223 is about the situation where the plugin opens a separate popup window with window.open(...). 

My plugin needs this to support an openid connect/oauth authentication workflow where the user is redirected to the login page of e.g. Facebook. So, the extra popup window is created to let the user fill in his Facebook username/password and after authentication the window is closed and execution is continued in the popup of the extension.

In Chrome (and Safari) this works without any problems. In Firefox, opening the window for authentication will automatically close the popup itself, which is not what I expect.

Since the window is created by the popup/plugin, I find it very surprising that this will cause the popup to close. In addition to this authentication workflow I can think of many scenarios where opening a new window from within the popup/plugin should not close the popup/plugin.

Perhaps, there is a workaround, or perhaps I'm not doing it in the right way, but since it is working in Chrome I was expecting it to simply work. Furthermore, since the authentication workflow is actually implemented in a third-party library (oidc-client), it is not desirable to have to change this code.

If needed I can provide a simple test add-on. Just let me know.

Comment 9

[:Gijs (away/busy until Mar 10)]

(In reply to Kris Maglione [:kmag] from comment #7)
> (In reply to :Gijs from comment #5)
> > Related: can someone attach a test add-on? Does the behaviour work correctly
> > in Chrome?
> 
> My understanding is that it does, but Chrome's auto-hide popups work
> differently from ours, and apparently they stay open when another browser
> window has focus, but close when something else in the same window gets
> focus.

But this sounds like a wider issue that's something webextensions popups need to match Chrome/Safari on, and for that reason perhaps something the webextensions team needs to look at? I don't think we want to change the behaviour, esp. for non-modal new windows, for our builtin popups.

Comment 10

[Neil Deakin]

On Linux, the popup disappears when the file picker opens just as we do. It doesn't reopen when the file picker is closed. Oddly, also on Linux, Chrome appears to be just using an overlay on the window and not a native widget for the extension popup. It does use a native popup widget on Windows and Mac. On Windows, it doesn't disappear when switching to another application, but does on Mac.

Note that I tested Chromium since I have no 64-bit Linux. It would be good for someone to test a proper version of Chrome.
 
I tested by downloading My Bookmarks from https://developer.chrome.com/extensions/samples and adding in a file picker.

Comment 11

[Kris Maglione [:kmag]]

(In reply to :Gijs from comment #9)
> But this sounds like a wider issue that's something webextensions popups
> need to match Chrome/Safari on, and for that reason perhaps something the
> webextensions team needs to look at? I don't think we want to change the
> behaviour, esp. for non-modal new windows, for our builtin popups.

I'd rather these popups behave consistently with our existing autoclose popups rather than try to ape the behavior of Chrome. I don't have a strong opinion on the behavior of non-modal popups opened by windows in these panels, but the file picker use case seems pretty clear. There's no point in opening a modal dialog for a panel and then closing the panel before that dialog closes.

If we're not going to handle it by keeping the popup open (which I think is the sensible option), then we should prevent modal dialogs from being opened at all.

(In reply to Neil Deakin from comment #10)
> On Linux, the popup disappears when the file picker opens just as we do. It
> doesn't reopen when the file picker is closed. Oddly, also on Linux, Chrome
> appears to be just using an overlay on the window and not a native widget
> for the extension popup. It does use a native popup widget on Windows and
> Mac. On Windows, it doesn't disappear when switching to another application,
> but does on Mac.

I'm less concerned about Chrome's behavior on Linux than Windows. I haven't tested this on Windows myself, but the reports I've heard are that the file picker works as expected from popups in Chrome. And I think it should probably work as expected in Firefox regardless of whether it works in Chrome.

Whether the popups stay open (and correctly stacked) when switching windows, in general, rather than just when something else in the same window receives focus is, as far as I'm concerned, a separate bug.

Comment 12

[:Gijs (away/busy until Mar 10)]

OK, so my takeaway from this is that:

- we should make opening modal native dialogs work for all popups (I don't think this should include alert/confirm/prompt, fwiw)
- we're less interested in making switching between different windows keep popups open in the other window

AIUI this would mean implementing changes in the XUL popup layer, so I'm moving the bug there and clearing the priority field. I don't know what our options are on Linux given the popup level confusion. Neil probably knows more than me.

Comment 13

[merijn.de.jonge]

(In reply to :Gijs from comment #12)
> OK, so my takeaway from this is that:
> 
> - we should make opening modal native dialogs work for all popups (I don't
> think this should include alert/confirm/prompt, fwiw)
> - we're less interested in making switching between different windows keep
> popups open in the other window
> 
> AIUI this would mean implementing changes in the XUL popup layer, so I'm
> moving the bug there and clearing the priority field. I don't know what our
> options are on Linux given the popup level confusion. Neil probably knows
> more than me.

Just to be sure: "make opening modal native dialogs work for all popups" included windows created with "window.open(...)" as in my case, right?

Comment 14

[Neil Deakin]

The only thing I can think of is to set a flag that disables rolling up when a file picker is opened and clears it afterwards. Possibly this could be done in HTMLInputElement::InitFilePicker.

Comment 15

[Kris Maglione [:kmag]]

(In reply to Neil Deakin from comment #14)
> The only thing I can think of is to set a flag that disables rolling up when
> a file picker is opened and clears it afterwards. Possibly this could be
> done in HTMLInputElement::InitFilePicker.

I wonder if we should just remove the autoclose attribute when DOMWillOpenModalDialog is fired on a descendant, and re-add it after DOMModalDialogClosed. It would probably be simpler than most other solutions.

(In reply to merijn.de.jonge from comment #13)
> Just to be sure: "make opening modal native dialogs work for all popups"
> included windows created with "window.open(...)" as in my case, right?

No, your window would not be modal. I'll re-open your original bug if we decide to go a route that only handles modal dialogs. We'll have to talk that over with UX.

Comment 16

[merijn.de.jonge]

(In reply to Kris Maglione [:kmag] from comment #15)
> No, your window would not be modal. I'll re-open your original bug if we
> decide to go a route that only handles modal dialogs. We'll have to talk
> that over with UX.
Any ideas when this we be, since the issue is really blocking me from getting my FireFox extension operational?

Comment 17

[Jan Zavřel]

(In reply to Neil Deakin from comment #4)
> No, the popup should close when you open another window. If you want a popup
> that isn't transient, then use noautohide.

How can I please use "noautohide" to achieve exactly this goal?

Comment 18

[Jan Zavřel]

(In reply to merijn.de.jonge from comment #2)
> Hi,
> 
> Is there any progress on this or any workaround?
> Seems like a showstopper for many plugins (including mine :-( ).
> 
> Thanks for any info.
> 
> Merijn

I tried to create a panel like this:
browser.browserAction.onClicked.addListener((tab) => {

  var popupURL = browser.extension.getURL("popup/anything.html");

  var creating = browser.windows.create({
    url: popupURL,
    type: 'panel',
	state: 'maximized'
  });
 
});
But it seems it does not have access to APIs like var querying = browser.tabs.query({currentWindow: true});. Is there any way for such a UI to gain this type of access (which normal popup has)?

Comment 19

[Kris Maglione [:kmag]]

We talked about this in the advisory group, and came to the conclusion that we definitely want to support the modal file dialog use case as soon as possible, but that other use cases for keeping the popups open should be tracked separately, and given a lower priority.

I'll file a separate bug tracking that issue. In the mean time, extensions that rely on that behavior should implement workarounds, such as opening a tab in place of the panel when such a popup is required, or using the identity API.

Comment 20

[merijn.de.jonge]

Does opening a tab and receiving user input in it not de-focus the extension popup and therefore close it?
Is identity API already available. I can't find it in the list of supported javascript APIs on https://developer.mozilla.org/en-US/Add-ons/WebExtensions.

Comment 21

[Kris Maglione [:kmag]]

(In reply to merijn.de.jonge from comment #20)
> Does opening a tab and receiving user input in it not de-focus the extension
> popup and therefore close it?

It would close the popup, yes. The tab would have to take over whatever flow the popup needed to open a window for.

> Is identity API already available. I can't find it in the list of supported
> javascript APIs on https://developer.mozilla.org/en-US/Add-ons/WebExtensions.

Yes. It was implemented in bug 1305421 but hasn't been documented yet.

Comment 23

[merijn.de.jonge]

Same thing happens with the identity API. It opens a popup, but this closes the extension's popup.
I will also report this as a bug at bug 1305421

Comment 24

[merijn.de.jonge]

My guess is that a popup window that is created by the extension's popup should not/never result in automatically closing this extension's popup.
Since the authentication API does not solve the issue, I would vote for increasing the priority of fixing this because lacking support for OAuth2 authentication flows would be a missed opportunity.

Comment 25

[Andrey Klochkov]

Hi,

This is a showstopper for my plugin too.
I use dropzone.js in the popup window so user can open a picture file from his machine and use it in the plugin.
It wasn't a problem in Add-on SDK. The popup window disappeared but the code was still running on background and the image was there when I opened the popup next time.
When I migrated to WebExtensions it seems like the thread is stopped when popup is auto-closed. I tried to put console.log statements and there is nothing in the log.

Do we have any working workaround?
Opening a tab in place of the panel and using the identity API doesn't help in my case.
Could you please explain how can I use 'noautohide' option?

It's working fine when I set the ui.popup.disable_autohide config value to true on about:config page. Is it possible to change it programmatically?
Setting the devtools.command-button-noautohide.enabled to true doesn't help.

Many thanks,
Andrey

Comment 26

[:Gijs (away/busy until Mar 10)]

(In reply to Kris Maglione [:kmag] (busy; behind on reviews) from comment #19)
> We talked about this in the advisory group, and came to the conclusion that
> we definitely want to support the modal file dialog use case as soon as
> possible, but that other use cases for keeping the popups open should be
> tracked separately, and given a lower priority.
> 
> I'll file a separate bug tracking that issue.

Did this happen?

Comment 27

[Kris Maglione [:kmag]]

(In reply to :Gijs from comment #26)
> (In reply to Kris Maglione [:kmag] (busy; behind on reviews) from comment
> #19)
> > We talked about this in the advisory group, and came to the conclusion that
> > we definitely want to support the modal file dialog use case as soon as
> > possible, but that other use cases for keeping the popups open should be
> > tracked separately, and given a lower priority.
> > 
> > I'll file a separate bug tracking that issue.
> 
> Did this happen?

No, but thanks for the reminder. I just filed bug 1366330.

Comment 29

[Kyle]

This same behavior occurs when downloading a file from the browser action popup as well (via anchor tag `download` attribute). The system window opens asking "What should Firefox do with this file?" "Open with" or "Save File" and the browser action popup is dismissed.

Is this something we could expect a fix for?

Comment 31

[jimscarver]

Yes. Can we expect a fix? We are unable to add ethereum accounts in metamask by json file due to this bug. We do not want to force our users to use chrome.

Comment 32

[Worcester12345]

Following this bug for "Duplicate Tabs Closer" extension compatibility.

Comment 33

[Firefox Bug Husbandry Bot]

Moving to Core:XUL per https://bugzilla.mozilla.org/show_bug.cgi?id=1455336

Comment 34

[rugk]

BTW that is also important (and annoying for WebExtension devs) when you e.g. want to request a permission from a popup window. When the user accepts the permission, the popup is already closed…

Comment 35

[lukashino]

Is there any update?

Comment 36

[xjsv24]

This is a show stopper for me also. I am using an input type="color". When the color picker dialog shows up the popup window closes and nothing happens.

Comment 37

[ueli.sarnighausen]

This is still am issue, the popup really should study open while a file is picked, this is especially annoying for filesharing add-ons

Comment 38

[vitor_seles]

Judging by the comments I don't think there will be an update for this anytime soon... :(

Does anybody know a workaround for this?

At first I had a problem with OAuth2 since Firefox closes the popup once a new window is open. The solution was to send OAuth2 data as a message to the background scripts and store it using the Storage then handle it once the popup opens.

But as for File Dialogs it's a different case now. I can't send the file data as a message to the background scripts because the listeners waiting for a file input are just lost once the popup closes.

What I'm trying to do now is trigger the File Dialog from the Background Page but I'm really not sure if this will work.

Honestly I feel that this autoclose behaviour from Firefox is rather a limitation other than anything else, I'm sure I'm not the only one having trouble porting an extension to Firefox because of this...

Comment 39

[:Gijs (away/busy until Mar 10)]

Luca, can you surface this / bug 1366330 for triage/prioritization by the add-ons team?

Comment 40

[vitor_seles]

Hey guys! To anyone who might come across this...

It seems the workaround for this is creating a new window and handling the File Dialog from there.

Even though the popup will close once the window is open, you can still communicate with background scripts using Messages.

So I just send the file data to the background script and save it using storage then read it later when the popup opens.

That's what helped me, hope it helps someone else!

Comment 41

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

(In reply to :Gijs (he/him) from comment #39)

Luca, can you surface this / bug 1366330 for triage/prioritization by the add-ons team?

Sure, I just added it to the list of topics to discuss in our weekly standup meeting.

I'm not clearing the needinfo assigned to me yet (to make sure I don't forget to comment here with the outcome of that discussion)

Comment 42

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

We briefly discussed about this during today's standup meeting:

• we were all in agreement that the attempt in bug 1366330 may be more of a workaround than an actual fix:

  • the attempt in that bug is based on "setting the noautohide property", and then having some custom logic that decide when we can close the popup (e.g. "when it does lose focus and no modal dialog or input-related popup still open for that browserAction popup window")

• we would like to hear the perspective of someone that may help us to decide how we may try to tackle this more appropriately in a lower layer:

  • despite this being an issue that the extensions are more likely to trigger at the moment, the issue itself is not strictly specific to extensions,
    any web-like content that we may load in a popup should be able to trigger the exact same issue (at the moment this isn't something that
    we do often in the Firefox UI for anything else, but Shane did recall that it used to be triggered by Firefox UI itself in the past, and maybe the
    Pocket button is one more case where we may be able to it the same kind of issue if any of those controls are used in the Pocket popup
    window?)

Hey Neil,
is there anyone that you can point us to get some help with looking for a reasonable strategy to fix?

Comment 43

[ueli.sarnighausen]

I'm coming at this from the extension, file picker side - maybe we can look at it like this, if the popup calls something and expects a callback or a promise to be coloure fulfilled, the popup should stay open, otherwise it probably should be closed.
I hope this helps, even though I can't contribute much codewise

Comment 44

[Neil Deakin]

• the attempt in that bug is based on "setting the noautohide property", and then having some custom logic that decide when we can close the popup (e.g. "when it does lose focus and no modal dialog or input-related popup still open for that browserAction popup window")

Setting and clearing the autohide attribute should work on Windows and Mac once the popup is open, but it looks like the code that handles this was incorrectly removed in bug 1278282, thinking that that code was a gtk2 only block. Putting back the change to nsMenuPoupFrame::AttributeChanged from that bug should make setting the noautohide attribute work again.

Better though would be to just add a function to XULPopupElement that just calls enableRollup() on that popup element, and remove the ifdef gtk bits from enableRollup. This way, we won't have an issue with the extra implications that noautohide means on gtk. This assumes you need access from js code. If not, you can just call nsXULPopupManager::EnableRollup, as is I assume the case with the file picker.

I don't know how the file picker works to be able to answer how it would determine which popup it was in when opening the dialog.

Comment 45

[techblazes]

Guess the bug isn't still resolved. I was porting my chrome extension to firefox and this is a blocker. Clicking on <input type=file> button closes the popup. Perhaps the devs could reproduce the functionality that keeps popup open (Disable popup auto hide from Inspector) and trigger it here. Wish I could contribute from a code level.

Comment 47

[vsch]

Same here, this bug prevents me from porting some functionalities from Chrome. Any update?

Comment 48

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 5 duplicates and 17 votes.
:enndeakin, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 49

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 50

[Aidan Welch]

(In reply to Release mgmt bot (nomail) [:suhaib / :marco/ :calixte] from comment #49)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

It is still relevant!

Comment 51

[Aidan Welch]

Attachment: Bug 1292701, 1366330 - Fix popup hiding while navigating file picker r=cmartin

Comment 52

[Anthony Ettinger]

I'm running into this issue trying to use file dialog as well. It works in chrome (popup.html stays open) but in firefox the popup is closed when I select a fie.

Comment 53

[Gregory Pappas [:gregp]]

(Setting leave-open because the patch in attachment 9323664 [details] will only fix this bug on Windows)

Comment 54

[:Gijs (away/busy until Mar 10)]

What's needed to move this forward? Aidan/Greg, looks like you've looked at this - are either of you working to update the patch in response to the review comment from Emilio?

Comment 55

[Gregory Pappas [:gregp]]

are you working to update the patch in response to the review comment from Emilio?

Not at the moment, but If Aidan is unavailable, I can pick it up if you want.

Comment 56

[Aidan Welch]

(In reply to :Gijs (he/him) from comment #54)

What's needed to move this forward? Aidan/Greg, looks like you've looked at this - are either of you working to update the patch in response to the review comment from Emilio?

I've been a little busy but will try to work on it- and work on a similar fix for Linux

Comment 57

[Aidan Welch]

(In reply to :Gijs (he/him) from comment #54)

What's needed to move this forward? Aidan/Greg, looks like you've looked at this - are either of you working to update the patch in response to the review comment from Emilio?

Okay, done

Comment 58

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0c47c1159e0a
1366330 - Fix popup hiding while navigating file picker r=cmartin

Comment 59

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/0c47c1159e0a

Comment 60

[Ray Kraesig [:rkraesig]]

Note that the Windows patch has been backed out due to the regression filed as bug 1844733.

Comment 61

[lawrence.sim.geo]

Any news on when this will be re-merged into an upcoming release? Was hoping this would be part of 117.0.

Comment 62

[:Gijs (away/busy until Mar 10)]

(In reply to lawrence.sim.geo from comment #61)

Any news on when this will be re-merged into an upcoming release? Was hoping this would be part of 117.0.

:rkraesig, can you comment on plans for this bug given the regression that was uncovered and caused this to be backed out?

Comment 63

[Ray Kraesig [:rkraesig]]

Usually the patch author's responsible for resolving the regression and resubmitting, no? If Aidan's not still interested in working on this (Aidan, are you?), then I don't think there are any plans at present.

Comment 64

[Aidan Welch]

(In reply to Ray Kraesig [:rkraesig] from comment #63)

Usually the patch author's responsible for resolving the regression and resubmitting, no? If Aidan's not still interested in working on this (Aidan, are you?), then I don't think there are any plans at present.

I would definitely still be interested in helping to fix this but that was my first attempt at a PR to Firefox, and I think I would need some guidance on resolving all the externalities this creates.

Comment 65

[Ray Kraesig [:rkraesig]]

(In reply to Aidan Welch from comment #64)

(In reply to Ray Kraesig [:rkraesig] from comment #63)

Usually the patch author's responsible for resolving the regression and resubmitting, no? If Aidan's not still interested in working on this (Aidan, are you?), then I don't think there are any plans at present.

I would definitely still be interested in helping to fix this but that was my first attempt at a PR to Firefox, and I think I would need some guidance on resolving all the externalities this creates.

I suspect resolving all the externalities will involve more than a small patch. (At the very least it requires establishing consensus on what constitutes "proper" behavior when, e.g., the user attempts to minimize the extension popup's parent window while the extension has a file dialog open.)

That said, improvement on the existing behavior should be possible with a small patch along the lines of what you've written. The easiest path forward is probably to resubmit the patch (still as D172884), requesting review from the new "#win-reviewers" group (r?#win-reviewers) instead of naming :cmartin directly. (Further discussion is probably more appropriate for Phabricator.)

Comment 67

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 68

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:enndeakin, since the bug has recent activity, could you have a look please?

For more information, please visit BugBot documentation.

Comment 69

[Aidan Welch]

(In reply to Ray Kraesig [:rkraesig] from comment #65)

(In reply to Aidan Welch from comment #64)

(In reply to Ray Kraesig [:rkraesig] from comment #63)

Usually the patch author's responsible for resolving the regression and resubmitting, no? If Aidan's not still interested in working on this (Aidan, are you?), then I don't think there are any plans at present.

I would definitely still be interested in helping to fix this but that was my first attempt at a PR to Firefox, and I think I would need some guidance on resolving all the externalities this creates.

I suspect resolving all the externalities will involve more than a small patch. (At the very least it requires establishing consensus on what constitutes "proper" behavior when, e.g., the user attempts to minimize the extension popup's parent window while the extension has a file dialog open.)

That said, improvement on the existing behavior should be possible with a small patch along the lines of what you've written. The easiest path forward is probably to resubmit the patch (still as D172884), requesting review from the new "#win-reviewers" group (r?#win-reviewers) instead of naming :cmartin directly. (Further discussion is probably more appropriate for Phabricator.)

Okay, I'll try to do so soon, I've been relatively busy!

Comment 70

[Aidan Welch]

Hi, sorry for all the delay, I was thinking it seems to me the most "correct" behavior would be allowing popups to stay open when other windows are selected. But staying at the same depth as the main browser window rather than drawing over other programs. However, I don't know if this could create other problems.

Comment 71

[reloia]

Hello, this issue has been open for almost 10 years, could we get an update on this?
This problem is causing significant issues when porting extensions from other browsers to Firefox (as stated on bitwarden/clients#3013 and LucasAschenbach/prompster#6.

In Bitwarden's case, for example, the autohide feature makes the biometric login not work because the popup uses other windows to verify the user identity.

In my opinion, to deliver a good user experience for people moving from other browsers to Firefox it would be best to add a toggle to allow the popup from a certain extension to avoid being closed when the main Firefox window loses focus as a hotfix until a better fix comes in or at least to close this decade-old issue.

Comment 72

[Mr. Beedell, Roke Julian Lockhart (RJLB)]

To consolidate all of the current discussion about this:

1. github.com/raindropio/app/issues/169

2. discourse.mozilla.org/t/32881

3. discourse.mozilla.org/t/12199/2

4. discourse.mozilla.org/t/10134/3

5. stackoverflow.com/questions/67770181

6. stackoverflow.com/questions/79339753

I'd have added these to BugFields#see_also, but I don't know whether that's what it's used for here.