if window created maximised, no manual size adjustment possible
Categories
(WebExtensions :: General, defect)
Tracking
(Not tracked)
People
(Reporter: buecher, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0
Steps to reproduce:
windows api: create, style: "maximised"
Actual results:
popup is maximised, but the 'set size manually' icon is not working (in the titlebar, however the icon is called).
So the popup is maximised, can be minimised, can be maximised again, but no custom size is possible.
Expected results:
even if the code requests the popup to be maximised, the user should be able to set size as desired.
Comment 2•4 years ago
|
||
Works for me on Linux. Maybe it's a Windows-only thing?
Comment 3•4 years ago
|
||
Ok, I traced it into the popup window being a "dialog":
https://hg.mozilla.org/comm-central/file/tip/mail/components/extensions/parent/ext-windows.js#l193
And dialogs have any feature not being requested or explicitly disabled to use OS default:
https://hg.mozilla.org/mozilla-central/file/tip/toolkit/components/windowwatcher/nsWindowWatcher.cpp#l1911
So what we see here is some not requested feature, which defaults to "on" for Linux, but "off" for Windows.
If I add "all" as feature request, I get the desired behavior in Windows as well.
But I was not able to determine WHAT feature is actually responsible for the max/unmax button. Any idea?
Comment 4•4 years ago
|
||
Additional information:
I want to have consistent behavior across different OS and I consider this as a bug which we should fix.
I tried all different features which I found in the source and none seemed to be dedicated to the max/unmax button. The only two options I see:
-
Using "dialog=no" feature:
Enabled the max/unmax button, but produces strange fails in our tests - not detecting popups as popups anymore - and I was not able to understand why and where the wrong type is produced. This test returns type normal instead of type popup: https://hg.mozilla.org/comm-central/file/tip/mail/components/extensions/test/browser/browser_ext_windows_events.js#l166 -
Using the "all" feature additionally:
Enabled the max/unmax button, but brings back the ugly location bar (location=no is ignored). As I see no need for that at all, it could be hidden permanently via CSS.
@Geoff: Any other ideas? Which way would you propose to move forward?
Comment 5•4 years ago
|
||
Is this bug specific to Thunderbird?
Comment 6•4 years ago
|
||
No, it is the same in Firefox.
Comment 7•4 years ago
|
||
So, this is a platform issue. Platform devs should find and fix the problem.
Comment 8•4 years ago
|
||
Hello,
I’m from QA and I’m attempting to reproduce the issue but I have limited knowledge regarding add-on building.
Could you please provide the add-on you used when you encountered the issue so I can confirm the problem? Thank you !
not really. I was needing that in my addon but obviously took it out, because it was not working, so on my end, the broken code is gone.
John did a lot of tests - maybe he has something that you can inspect?
Comment 10•4 years ago
|
||
Klaus, could you try to re-create the code? Having a reproducible situation is needed to get something fixed. If I do that, I cannot guarantee to hit your bug.
Comment 13•4 years ago
•
|
||
Steps to reproduce. It means we need an example add-on and instructions which allows us to reproduce the described bug without having to guess anything.
Comment 14•3 years ago
|
||
Closing as incomplete, if you can provide more details, feel free to reopen.
Description
•