1366330 - Keep autoclose popups opened when opening a modal file picker dialog

Status: NEW

(Core :: XUL, enhancement)

Description

[Kris Maglione [:kmag]]

Bug 1292701 is about the general case of keeping popups open when they open any modal dialog. This is about the specific case of the file picker dialog, which is the one that comes up most often, and is easiest to address.

The easiest solution is probably to just add the noautohide attribute to a popup when we're about to open a file picker, and remove it after the file picker closes. This should be doable without any native code changes.

Comment 3

[Ale]

Is there any timeline for this bug? It was opened 4 months ago to allow a quick fix of the file picker problem (which is blocking for porting many add-ons to Web Extensions, and was reported 8 months ago)... now Firefox 57 is around the corner...

Comment 4

[Epistemex]

Will there be any fixes for this for the v58 release?

Comment 5

[Kris Maglione [:kmag]]

No, though at this point we should probably aim for 59

Comment 6

[Ale]

I don't know exactly how the process works for ESR releases, however if the only option to have this bug fixed in the next ESR is having it in version 59, then it would be an important deadline in my opinion

Comment 7

[sdaniele3]

Is there a priority for this? It effects addons that use the browserAction menu/panel as the primary means of interaction. Having to spawn an internal page just for file upload is horrendous UX.

Comment 8

[Thomas Wisniewski]

Attachment: 1366330.diff

Hmm. It doesn't look like there are any events being fired when non-Android file pickers are opened/closed, so native code changes are needed after all.

I took a shot at making a patch, but while the events are being fired, it's too late to add noautohide at that point (the popup still closes).

I'll take another shot ASAP, but for now here's the patch I tried (though I've only coded up the bits to make it "work" with the GTK3/Linux filepicker, not the other OS file pickers).

Comment 9

[Thomas Wisniewski]

kmag, it actually doesn't seem as though adding/removing noautohide is honored the way we think it should be, regardless of whether the events are firing too early.

If I do this in ViewPopup.attach for a browseraction popup:

>let panel = this.viewNode.closest("panel");
>panel.setAttribute("noautohide", "true");
>setTimeout(() => {
>  panel.removeAttribute("noautohide");
>  Cu.reportError("REMOVED " + panel.getAttribute("noautohide"));
>}, 100);

Then after I summon the popup, it never dismisses again (whether I click around or summon a file dialog, even though the noautohide attribute was apparently removed).

Similarly, the attribute only seems to be honored when I add it in the attach method, rather than in a setTimeout or listener. That is, this works (the panel doesn't autohide):

>let panel = this.viewNode.closest("panel");
>panel.setAttribute("noautohide", "true");

But this does not, despite the console logging that the attribute was in fact added to the dialog (clicking around still dismisses the panel, as does opening a file dialog).

>let panel = this.viewNode.closest("panel");
>setTimeout(() => {
>  panel.setAttribute("noautohide", "true");
>  Cu.reportError("ADDED " + panel.getAttribute("noautohide"));
>}, 100);

Then again, I only tested in Linux. Perhaps there is something OS-specific going on there that I'm unaware of.

Either way, the same happens when I try using event listeners instead of setTimeout, so I think I'm stuck.

Comment 10

[Firefox Bug Husbandry Bot]

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