Closed Bug 1389749 Opened 7 years ago Closed 7 years ago

browserAction popup is closed when browser window loses focus

Categories

(WebExtensions :: Untriaged, defect)

57 Branch
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: rotemdan, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20170811100330

Steps to reproduce:

1. Install any extension having a browser action popup.
2. Click on the icon to open the popup.
3. Click anywhere outside the browser window (e.g. on windows, click the taskbar or a secondary open window)


Actual results:

The popup is hidden.


Expected results:

The popup should stay visible. This is the current Chrome behavior as of v60.
Summary: browserAction popup is hidden when browser window loses focus → browserAction popup is closed when browser window loses focus
Just wanted to expand a little:

Of course there's no "fundamental" reason why the popup must stay visible when the window loses focus. It is true that Chrome has that behavior (which I personally agree with) when moving focus between windows (at least in Win10). However I noticed the popup does close when the browser window is minimized. I'm not sure if that's completely planned or just accidental (I will consider reporting it in the Chromium tracker if needed).

Anyway, I'm personally trying to encourage a move to start considering these browser "actions" more like temporary application UIs, as often they are used in that way (despite probably not being originally designed to accommodate that). It seems reasonable to me that if a user focuses on another window (or minimizing/maximizing/resizing the browser window), they are acting on a higher level context on the OS level and that action should not impact anything happening within the bounds of the application (similar to the lack of impact on popup HTML elements if rendered within the page content).
Flags: needinfo?(mixedpuppy)
Popups in Firefox are designed to be transient and to close automatically with any shift of focus away from them.  Changing that would be inconsistent with the rest of the ui.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Flags: needinfo?(mixedpuppy)
Resolution: --- → WONTFIX
The subject of this issue is to consider the case where the browser loses focus (or minimized/maximized). Since the browser is a container and the "popup" (which is a often a misnomer since in practice it is often used to render a stateful application UI, rather than just a menu) exists within it, actions performed outside of the browser scope shouldn't impact its internal components (in my view).

I'm not sure what is the reference for other "popups" in Firefox. I'm not aware of similarly rendered examples (both in looks and in utility) outside of the extension API (XUL doesn't matter anymore). The classical idea of a "popup window" is actually simply a secondary browser window without a location bar, which when loses focus is not destroyed, just falls to the background., which is nothing like what is rendered by a browser action.

Again I'm using the term "popup" because that's how it was formally described by the Chrome Extension API. In practice it is not a popup, it is a multi-purpose temporary overlay panel rendering a custom webpage and script.
Product: Toolkit → WebExtensions

There is a use case when popup should survive blur event: transient focus lost due to switching of keyboard layout. Behavior consistency across Firefox UI is quite disappointing at such moments. Chrome UI elements are resistant to temporary focus lost, so user experience is much better.

This is a case of X11 window system (Xorg) and user setup with at least 2 keyboard layouts with completely different letters, e.g. Latin and Cyrillic, so layout is switched quite frequently. Xkb allows to switch layouts without focus out X11 event. On the other hand in Gnome such feature is blocked and layouts are switched through global shortcut (key grab in X11 parlance). In X11 global key grab causes a pair of focus out and focus in events received by active window. Besides Gnome, at least iBus uses global shortcuts to switch input methods. Firefox handles such transient events just as switching to another window closing popups, context menus, sending blur event to web pages (with "fancy" actions).

It is horrible when an attempt to switch keyboard layout (e.g. to type something in an input field) dismisses the dialog.

You need to log in before you can comment on or make changes to this bug.