browser.windows.create({type:'popup'}) cannot use the GUI to maximize the window
Categories
(WebExtensions :: Frontend, defect, P3)
Tracking
(firefox97 affected, firefox98 affected, firefox99 affected)
People
(Reporter: ryanakashi, Unassigned)
Details
(Whiteboard: [win:sizing])
Attachments
(2 files)
Steps to reproduce:
Create a new window via browser.windows.create({type:'popup'}). The new window created cannot be maximized by pressing the square in the top right corner:
However, this window can still be maximized by using:
browser.windows.update(WINDOW_ID,{state:'maximized'})
To me, this indicates an inconsistency with the Firefox GUI that is blocking users from maximizing “popup” or “borderless” windows via the square in the top right of my browser. This behavior works perfectly fine in Chrome, and I don’t see a reason why it shouldn’t be enabled on Firefox as well.
In addition, this is not documented in the "Chrome incompatibilities" section on the Mozilla website either:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Chrome_incompatibilities
Actual results:
If you click the maximize button, nothing happens.
HOWEVER, if you use browser.windows.update(WINDOW_ID,{state:'maximized'}), it works just fine.
Expected results:
When you click the maximize button, the window should maximize just like normal Firefox windows.
Comment 1•3 years ago
|
||
Could you please provide some extra steps about how to use and where to execute the syntax from the bug?
Thanks.
Reporter | ||
Comment 2•3 years ago
|
||
Yes! To test this bug, use a Windows 10 operating system and load up a simple Firefox Addon via about:debugging.
Inside of the content script running in the background, run the following line of code:
browser.windows.create({type:'popup', url:'https://www.youtube.com/'})
Alternatively, you may also test this by visiting about:debugging, search for a previously loaded add on, select "Inspect", and then type the above line of code into the console.
You will notice that the window will appear, however, you will be unable to maximize it by clicking the top right of the corner. You will still be able to maximize the window via the browser.windows.update(WINDOW_ID, {state:'maximized'}) API.
As per a previous thread, correct behavior is confirmed to work on Manjaro Linux with XFCE:
https://discourse.mozilla.org/t/browser-windows-create-type-popup-unable-to-maximize/93528/3
Please let me know if any additional information is needed and I am happy to answer.
Updated•3 years ago
|
Comment 3•3 years ago
|
||
Hello,
I reproduced the issue on the latest Nightly (99.0a1/20220222190424), Beta (98.0b8/20220222185824) and Release (97.0.1/20220216172458) under Windows 10 x64.
Proceeding with the STR from Comment 2, running the browser.windows.create({type:'popup', url:'https://www.youtube.com/'})
snippet in the console of an installed extension will produce a window which cannot be maximized using the Maximize button from the top right corner of the window (it’s greyed out). For further details, see the attached screenshot.
I’ve also tested this on Ubuntu 16.04 LTS and the issue does not occur on this platform. The Maximize button is available and functional.
Comment 4•3 years ago
|
||
Comment 5•3 years ago
•
|
||
I'm guessing the intention here was that popup windows wouldn't have the maximize button enabled. This is not a web extensions bug, but how the Firefox front-end team decided popups should behave.
The only thing we can do from the extensions side is prevent you from maximizing popup windows using code, to avoid the inconsistency, which is probably the opposite of what you would want.
In any case, I'm moving this to the Firefox component for them to decide if this is something they would want to address (or even if they would like us to actually prevent extensions from being able to maximize popup windows, for consistency).
Comment 6•3 years ago
|
||
It looks like this window is opened with the resizable feature [0] but it can't be maximized.
Reporter | ||
Comment 7•3 years ago
|
||
@Tomislav Jovanovic
After testing on Linux, Windows, and Mac, the Windows behavior is the only one that deviates from the typical browser behavior of a non-popup browser window.
In other words, Linux and Mac are able to maximize as a user would expect, while a Windows user would not be able to maximize. Particularly, Windows popout window behavior is the only behavior that deviates between any combination of Normal vs. Popout browsers on Linux and macOS.
From a user experience perspective, this hurts Windows Firefox users because, in 2022, everybody knows and understands how to maximize windows, and the expectation is that all windows can be maximized. By preventing this feature, users become more confused by the fact that they are unable to maximize a specific window than the action of actually maximizing it.
This also leads to inconsistencies for Firefox developers when creating and uploading extensions - feature sets will work properly for Mac and Linux Firefox users, however, will fail to behave properly on Windows. Something like this becomes especially difficult to debug when trying to build cross-platform extensions, where changes such as this are not documented.
Not only that but also from a development perspective it is probably a lot easier to allow maximizing of the popout window on Windows than attempting to block it for all other operating systems :-D.
Hopefully, you'll be able to keep us updated on what the Firefox component team decides?
Comment 8•3 years ago
|
||
The severity field is not set for this bug.
:enndeakin, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 9•2 years ago
|
||
The relevant code is in xpfe/appshell. (And also in browser/components/extensions, which hasn't changed relevantly since :mstriemer noted it.)
I'm not sure why popups are being created as "dialog"
at all, though — the comment in question implies that they're intended for system-like dialogs in the style of ::DialogBoxW
, not secondary windows. If there was a decision made to make these the way that they are, rather than merely being the fallout of unrelated decisions, I believe it would have to have been made in bug 1253128.
Sending back to WebExtensions for reconsideration.
Updated•2 years ago
|
Updated•2 years ago
|
Description
•