1378527 - popups opened from a panel cause the panel to close

Status: NEW

(Core :: XUL, defect)

Description

[sblask]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170612122310

Steps to reproduce:

Create a webextension with a toolbar button that bring up an options popup:

    "browser_action": {
        "browser_style": false,
        "default_icon": "icon.svg",
        "default_popup": "options/options.html",
        "default_title": "__MSG_browserActionLabelDefault__"
    },

Add an input with type color.
Click the button and then the color chooser.


Actual results:

The color chooser comes up, but the options popup disappears. So whatever color you choose, it's not applied in the options popup, making the input unusable.


Expected results:

The options popup should stay up and the chosen color should be applied to the input element. (Works like this in Chrome)

Comment 1

[Shane Caraveo (:mixedpuppy)]

Some clarity on the STR.

When any popup is opened from a panel, the panel is closed.  In this case, the color picker opens causing the panel to close, thus you are unable to select a color using this mechanism.  This is a long standing issue with our panels, and really any input element would work, for example a file picker.

Comment 2

[Shane Caraveo (:mixedpuppy)]

There is no current workaround for this, it would require a change in the panel code to make something general.

Comment 3

[Neil Deakin]

Please don't put random webextensions bugs in the xul component.

Comment 4

[Shane Caraveo (:mixedpuppy)]

(In reply to Neil Deakin from comment #3)
> Please don't put random webextensions bugs in the xul component.

This isn't a random webextension bug.  Panels close when a sub-panel is opened, nothing to do with webextensions.  Where do you propose this goes?

Comment 5

[Neil Deakin]

OK, so a testcase would have helped here.

Chrome seems to keep the popup panel open until you either click outside on the same window or press Escape, but doesn't close it in any other case, for example clicking on some other window. Some behaviour, I would consider a bug, for example, right-clicking on the url bar leaves the panel open, makes the urlbar look focused, but doesn't allow one to type in it. Chrome also leaves the color picker open even when the panel is closed.

I think you would need to decide on what conditions the panel is expected to remain open and on which conditions it would be closed. Generally our behaviour is to either close panels always when one switches to some other UI or application, or to never close them.

Comment 6

[Shane Caraveo (:mixedpuppy)]

This issue has always existed in popups, its more prevalent because of webextensions, but it's still a xul/panel issue.  What component can we put this into?

Comment 7

[Neil Deakin]

Well, there are three options here (assuming do nothing isn't one of them):

1. Never hide the panel automatically for panels that need this. This is easily done by making the panel noautohide. I assume though that the extensions system wouldn't know whether to do this or not.
3. Use the Chrome approach which is similar to 1, but something is added which closes the popup when clicking in the browser window. This is the most hacky of the solutions. I think this code would still be added to the extensions panel specifically.
2. Add something to the colourpicker form control so that it checks if it is inside a panel and prevents the panel from closing while the colourpicker is being opened. This code would be added to the form controls code somewhere.

Comment 8

[David Durst [:ddurst]]

Thanks. If 1 is a non-option, and 3 is hacky, then we're looking at 2. Same question though: what component should we move that to?

Comment 9

[Neil Deakin]

The colourpicker could look for an enclosing popup and prevent the popup from hiding while the colorpicker is being opened by cancelling the popuphiding event. This would then be 'Layout : Form Controls' if you want a solution specific to the colourpicker.

A variation would be to set something on the popup itself that could prevent it from closing. That might be advantageous if there were other situations where this was needed.

Comment 10

[Shane Caraveo (:mixedpuppy)]

Another example is the file picker.

Comment 11

[David Durst [:ddurst]]

(In reply to Neil Deakin from comment #9)
> The colourpicker could look for an enclosing popup and prevent the popup
> from hiding while the colorpicker is being opened by cancelling the
> popuphiding event. This would then be 'Layout : Form Controls' if you want a
> solution specific to the colourpicker.
> 
> A variation would be to set something on the popup itself that could prevent
> it from closing. That might be advantageous if there were other situations
> where this was needed.

That variation is a better solution (especially per #c10). But so far they all seem form control-y to me anyway (judging from a sub-panel that ostensibly is used to populate a value on the prior panel).

Comment 15

[juraj.masiar]

Why still Status: UNCONFIRMED and no priority?
It would be really nice to have. I mean, file input is pretty common element so not being able to use it in popups at all is bad.

Comment 16

[kernp25]

I have to disable the file picker in my add-on.

Will this bug be ever fixed?

Comment 17

[Shane Caraveo (:mixedpuppy)]

It is a low priority since the work around of using a tab exists. I'm not sure that form controls is the right component though. The problem would need to be addressed more generally with panels, allowing them to remain open during any kind of sub-popup control. Some of those controls are complicated to deal with as they use OS-level controls (e.g. colorpicker)

Comment 21

[ainzzorl]

(In reply to Shane Caraveo (:mixedpuppy) from comment #17)

It is a low priority since the work around of using a tab exists. I'm not sure that form controls is the right component though. The problem would need to be addressed more generally with panels, allowing them to remain open during any kind of sub-popup control. Some of those controls are complicated to deal with as they use OS-level controls (e.g. colorpicker)

Could you explain the work around of using a tab?

I also can't make file picker work with my add-on.

Comment 22

[juraj.masiar]

You have to reopen your `popup.html' in a new tab like a normal page.
It's a terrible workaround though and pretty shitty UX :(

Comment 24

[williamzijl7]

Attachment: test-extension 1 (pops up a file picker dialog)

I'm not sure why this is reported as UNCONFIRMED. I've attached a minimal reproducer. See https://bugzilla.mozilla.org/show_bug.cgi?id=1762774 for reproduce steps.

Could someone take another look at this? It will be nice to have the correct labels assigned to this bug.

Comment 25

[Daniel Holbert [:dholbert]]

Thanks. I can reproduce with the attached extension (in comment 24).

(In reply to Shane Caraveo (:mixedpuppy) from comment #17)

I'm not sure that form controls is the right component though. The problem would need to be addressed more generally with panels, allowing them to remain open during any kind of sub-popup control.

Agreed. Form controls happen to be one thing that spawn new windows and cause the popup to lose focus, but there are other things as well; e.g. traditional window.open(..., 'popup=true'); style popups do as well.

I can reproduce this bug with a modified version of the comment 24 extension, where the button triggers a window.open popup instead of a file-picker. That makes the extension popup disappear in Firefox, but not in Chrome.

So this bug is about popup panels themselves and what causes them to maintain vs. lose-focus-and-disappear. I'm tentatively reclassifying as XUL under that framing. (XUL is largely removed these days but nsXULPopupManager still exists, and I think it's what manages these WebExtension popups.)

Comment 26

[Daniel Holbert [:dholbert]]

Attachment: test extension 2 (pops up a window.open() style popup)

Comment 27

[Daniel Holbert [:dholbert]]

Attachment: test extension 2 (pops up a window.open() style popup)

Comment 28

[Daniel Holbert [:dholbert]]

Attachment: screencast showing the behavior with window.open() popups in Chrome vs. Firefox

Here's a screencast of testcase 2 in Chrome vs. Firefox.

In Chrome, the extension popup-panel remains open even after the window.open-spawned window appears and gains focus (though it does auto-close if I try to interact with it again [not shown in the screencast] or if I close the new window, at t=7s in the screencast).

In Firefox, the extension popup-panel closes immediately as soon as the window.open-spawned popup-window appears (i.e. as soon as I click the button, t=12s in the screencast).

(window.open() might not be a super useful thing for an extension to do (or maybe it is? I'm not sure). I'm just using it to demonstrate that this Firefox-vs-Chromium behavior-difference isn't specific to form control popups, but seems to apply to anything that can generate a new OS-level dialog/window and cause the panel to lose focus.)