Open Bug 1380184 Opened 7 years ago Updated 2 years ago

windows.create type:"popup" overlaps other applications on Linux

Categories

(WebExtensions :: General, enhancement, P5)

enhancement

Tracking

(firefox57 wontfix)

Tracking Status
firefox57 --- wontfix

People

(Reporter: u462496, Unassigned)

Details

(Keywords: dupeme)

Attachments

(1 file)

Create extension UI window using windows.create({ type: "popup", ... })

Mac OS X:

Focus another window (such as browser window).  If "popup" window overlays the newly focused window, it will be hidden in the background behind the newly focused window.

Linux:

Focus another window (such as browser window).  If "popup" window overlays the newly focused window, it still remains on top of the newly focused window.

The same corresponding behavior occurs with type:"panel".

Which is the expected behavior?

To me, "popup" implies the window should go into the background (or be hidden completely).
Here is an addon to demonstrate the effect.  Click on the browserAction button to open the UI window.

Note: The addon is not signed, so it will have to be unzipped, installed in the back door and loaded temporarily from about:debugging.
Component: WebExtensions: Untriaged → General
Product: Toolkit → Firefox
Component: General → XP Toolkit/Widgets: Menus
Keywords: dupeme
Product: Firefox → Core
Summary: windows.create type:"popup" focus behavior differs between OS X and Linux → windows.create type:"popup" (XUL popup level=top) overlaps other applications on Linux
Summary: windows.create type:"popup" (XUL popup level=top) overlaps other applications on Linux → windows.create type:"popup" (XUL popup) overlaps other applications on Linux
I'm a little confuse about your annotation "(XUL popup)".  AFAICT, this method still creates a chrome window.  Elsewise I would have not felt the need to file bug 1344573.
(In reply to Kevin Jones from comment #2)
> I'm a little confuse about your annotation "(XUL popup)".  AFAICT, this
> method still creates a chrome window.  Elsewise I would have not felt the
> need to file bug 1344573.

Looking at the code, you're correct! I misunderstood. It would be kind of helpful if the WebExtensions folks who moved this to Firefox gave more context as to why they think it's a Firefox bug, rather than just moving straight to Firefox::General.

Andy, can someone who knows what this webextension API actually *does* comment as to what it is that is buggy in platform/core/XUL/whatever?
Flags: needinfo?(amckay)
Summary: windows.create type:"popup" (XUL popup) overlaps other applications on Linux → windows.create type:"popup" overlaps other applications on Linux
Component: XP Toolkit/Widgets: Menus → Untriaged
While we're on the subject, I don't quite follow the use of the terms "panel" and "popup" as create types.  Those terms seem to imply a behavioral relationship with the XUL menus of those kind.  I can see that they don't display a tabs bar, but other than that I find nothing similar with the XUL panel/popup.  Also type "panel" and "popup" seem to do exactly the same thing, so I'm not sure why we have two different type designations.
windows.create creates a Window using chrome://browser/content/browser.xul, with these args https://dxr.mozilla.org/mozilla-central/source/browser/components/extensions/ext-windows.js#149

But once WebExtensions has created it, it's out of our hands and any further behaviour isn't dependent upon WebExtensions. If the bug is that the windows have different behaviours with focusing on different platforms that doesn't seem to be a WebExtensions bug. For example, as I understand it, just calling window.open would exhibit similar behaviour. So I'm ni'ing Kevin to check that is the issue.

Regarding comment 4 we note that we mention in the docs that panel and detached_panel are not supported on Firefox: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/windows/CreateType - they are present for compat with Chrome which does support them and the terminology came from Chrome not XUL.
Flags: needinfo?(amckay) → needinfo?(kevinhowjones)
(In reply to Andy McKay [:andym] from comment #5)
> windows.create creates a Window using chrome://browser/content/browser.xul,
> with these args
> https://dxr.mozilla.org/mozilla-central/source/browser/components/extensions/
> ext-windows.js#149
> 
> But once WebExtensions has created it, it's out of our hands and any further
> behaviour isn't dependent upon WebExtensions. If the bug is that the windows
> have different behaviours with focusing on different platforms that doesn't
> seem to be a WebExtensions bug. For example, as I understand it, just
> calling window.open would exhibit similar behaviour. So I'm ni'ing Kevin to
> check that is the issue.

Yes, that is correct.  Linux behaves the same way using window.open() dialog=true.
 
> Regarding comment 4 we note that we mention in the docs that panel and
> detached_panel are not supported on Firefox:
> https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/windows/
> CreateType - they are present for compat with Chrome which does support them
> and the terminology came from Chrome not XUL.

Actually, if I interpret the doc correctly, the inverse is true, Firefox is the only browser that supports both type `panel` and `detached_panel`.  The irony is that, in windows.create() they really have no particular meaning other than the fact that they are NOT either `null` or "normal".  Any string other "normal" here results in the same features being applied.  If I am reading the doc correctly, `detached_panel` is not supported by any other browser than Firefox.  So I am wondering why `detached_panel` type even exists in Firefox unless there are future plans for this type either in Firefox or one of the other browsers?  The language has a strong implication that there should be some difference between a `panel` and a `detached_panel`, though at this point there is none.
Flags: needinfo?(kevinhowjones)
(In reply to Kevin Jones from comment #6)
> ...If I am
> reading the doc correctly, `detached_panel` is not supported by any other
> browser than Firefox.  So I am wondering why `detached_panel` type even
> exists in Firefox unless there are future plans for this type either in
> Firefox or one of the other browsers?  The language has a strong implication
> that there should be some difference between a `panel` and a
> `detached_panel`, though at this point there is none.

Investigating a little further, as far as Chrome goes, `detached_panel` type was eliminated in October 2016:

https://chromium.googlesource.com/chromium/src.git/+/ca1dd5ae53fc34528cb5cff4086b3ec96ac4c9fb

So `detached_panel` did exist in Chrome at one time, probably explaining the reason `detached_panel` began to exist in Firefox.  I wonder if there is any reason for it to exist in Firefox any longer.
(In reply to Kevin Jones from comment #7)
> I wonder if there is any
> reason for it to exist in Firefox any longer.

That is to say, in documentation, as it doesn't really "exist" anyway.
Dave - could you provide some insight here into whether we should have both panel and detached_panel at this point?
Component: Untriaged → XUL
Flags: needinfo?(dtownsend)
Component: XUL → Window Management
> Yes, that is correct.  Linux behaves the same way using window.open() dialog=true.

Using 'dialog=true' will hint to the window manager that this is a dialog box. If you don't want it to behave that way, then I would suggest not using the dialog flag.
Component: Window Management → WebExtensions: General
Product: Core → Toolkit
I defer to Neil here.
Flags: needinfo?(dtownsend)
Product: Toolkit → WebExtensions
Priority: -- → P5
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: