Closed Bug 1684933 Opened 4 years ago Closed 3 years ago

if window created maximised, no manual size adjustment possible

Categories

(WebExtensions :: General, defect)

78 Branch
defect

Tracking

(Not tracked)

RESOLVED INCOMPLETE

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.

sorry, it is state, not style

Works for me on Linux. Maybe it's a Windows-only thing?

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?

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:

  1. 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

  2. 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?

Is this bug specific to Thunderbird?

No, it is the same in Firefox.

So, this is a platform issue. Platform devs should find and fix the problem.

Component: Add-Ons: Extensions API → General
Product: Thunderbird → WebExtensions
Version: 78 → 78 Branch

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 !

Flags: needinfo?(buecher)

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?

Flags: needinfo?(buecher)

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.

Please provide STR, or close this as incomplete.

Flags: needinfo?(buecher)

what is a STR?

Flags: needinfo?(buecher)

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.

Closing as incomplete, if you can provide more details, feel free to reopen.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.