1811326 - browser.windows.update size/position incorrectly limited

Status: ASSIGNED

(WebExtensions :: General, defect, P3)

Description

[Daniel B.]

Attachment: firefox window bottom.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/109.0

Steps to reproduce:

Use my Firefox extension ResizeIT 2 to set window position and size, so Firefox window fills entire vertical space, from top of screen to top of taskbar, using the browser.windows.update() API.

Actual results:

Firefox refuses to use 5 pixels between lower window border and top of taskbar, see screenshot. Firefox does not allow the window (even if way smaller) to be positioned such that bottom of window enters this space.

Expected results:

Firefox should not be restricting window size at all. By manually resizing the window, I can achieve any size and position I want.

In the first place, Firefox should properly remember its last size without requiring an extension to fix this broken behavior. This "airgap" has existed for quite some time, but the extension API limit is new in Firefox 109.

Comment 1

[Daniel B.]

It would appear that height is not limited at all. Firefox will happily move the top of its window outside the screen so long as the bottom hovers 5 pixels above the taskbar.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Alex Cornestean]

Hello,

I reproduced the issue on the latest Nightly (111.0a1/20230122211034), Beta (110.0b4/20230122190604) and Release (109.0/20230112150232) under Windows 10 x64 and partially under Ubuntu 16.04 LTS.

Windows:

Using the ResizeIT 2 extension (https://addons.mozilla.org/en-US/firefox/addon/resizeit-2/) and setting the “Top” parameter in the extension’s options page to 1000 for one of the available presets (thinking that a high enough value will force the browser window to stick to the taskbar) and then using that preset will indeed not cause the browser window to be positioned in such a way that it touches the taskbar. It always leaves a gap between the window and taskbar.

The same seems to be true for the “Left” parameter. Setting it to 0 (zero) which would mean the window should stick to the left side of the screen, will leave a gap between the left side of the screen and browser window.

Linux:

For Linux, which in my case has the dock on the left side of the screen (and cannot find a way to move it), setting the “Top” parameter to 1000 will cause the bottom of the window to touch the bottom of the screen, however, setting the “Left” parameter to 0 will still cause the same issue as on Windows i.e. the browser window will not stick to the dock, but instead leave a gap between the dock and window. That is why I previously mentioned that I could only partially reproduce the issue on Linux.

See the attached screenshots for more details.

Comment 4

[Alex Cornestean]

Attachment: 2023-01-23_11h03_23_Windows.png

Comment 5

[Alex Cornestean]

Attachment: Linux.png

Comment 6

[Alex Cornestean]

Performed a mozregression and found the following:

2023-01-25T09:03:38.172000: DEBUG : Found commit message:
Bug 1271047 - Place "popup" type window to given coordinates r=mixedpuppy

Differential Revision: https://phabricator.services.mozilla.com/D73419

Corresponding pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4feaa76d2f0d8fafedd56aee84c57f07f17ed527&tochange=69deea5582459dcdfaa43c5358ecccc44ffafb76

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1271047

:yuki, since you are the author of the regressor, bug 1271047, could you take a look?

For more information, please visit auto_nag documentation.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1271047

Comment 9

[YUKI "Piro" Hiroshi]

(In reply to Alex Cornestean from comment #6)

Performed a mozregression and found the following:

2023-01-25T09:03:38.172000: DEBUG : Found commit message:
Bug 1271047 - Place "popup" type window to given coordinates r=mixedpuppy

Differential Revision: https://phabricator.services.mozilla.com/D73419

Corresponding pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4feaa76d2f0d8fafedd56aee84c57f07f17ed527&tochange=69deea5582459dcdfaa43c5358ecccc44ffafb76

The found regression range looks wrong for me. I've confirmed this restriction on Firefox 60.9.0ESR on Windows 10 with following steps:

1. Start Firefox 60.9.0ESR.
2. Install ResizeIT 2 2.1.1. https://github.com/fuzzykiller/resizeit2
3. Go to about:debugging and open debugger for ResizeIT 2.
4. See screen.availWidth and screen.availHeight. They are 3440x1440 for me.
5. Go to ResizeIT 2's options page and set the 1st item: top=0, left=0, width=3440, height=1440.
6. Click the toolbar button of ResizeIT 2 and click the box "1".
7. The browser window is resized. Measure its dimensions.
   • The expected result: the dimensions of the window is x=0, y=0, width=3440, height=1440.
   • On the browser console (Ctrl-Shift-J) [window.screenX,window.screenY,window.outerWidth,window.outerHeight] says: Array [ 0, 0, 3440, 1440 ] (expected, but wrong size)
   • Capturing the screenshot with PrintScreen and paste it to GIMP, and select the window size. The actual dimension of the browser window is: x=5, y=0, width=3430, height=1435 (unexpected, but correct size)

Do I misunderstand what is the problem? Could you describe concrete steps to reproduce and expected/actual result like above?

Comment 10

[Daniel B.]

Not sure how the in-page JS objects (window, screen) are related here. Here goes anyway:

Screen is 2560x1440, it has a taskbar on it, DPI scaling is at 100%. screen.availHeight is 1400 (correct, measured on screenshot). screen.availHeight has not changed between working and broken versions. Both report 1400. When I vertically maximize the Firefox window (using the Windows snap thingy), it reports window.outerHeight as 1405 (incorrect) and window.screenY as 0 (correct). When Firefox is fully maximized (filling entire screen), window.outerHeight is 1416 (even more incorrect) and window.screenY as -8 (incorrect but consistent with outerHeight at least).

I want the bottom border behind the taskbar, so my desired height (set in ResizeIT 2 extension) is 1405 + 1 = 1406. Applying this preset results in window.outerHeight being 1406 (OK) and window.screenY being -6 (correct but not OK, top of window is cut off).

I do not think Firefox ESR is a good choice to test this. On regular 108, the error described above does not occur. On regular 109, it does. The offending change cannot be anywhere else. In Firefox ESR 68, 78 and 91, things work as in 108: The window appears at the exact position and size it is supposed to. It is touching the taskbar and will even extend behind the taskbar if requested to do so.

Comment 11

[YUKI "Piro" Hiroshi]

Thanks, I've confirmed that the problem with following steps:

1. Put the taskbar bottom of the screen and disable its "auto hide" option.
2. Start Firefox and see screen.availHeight. Assume that it is 1400.
3. Install ResizeIT2.
4. Go to ResizeIT 2's options.
5. Set the first item's height as screen.availHeight + 5 (assume that it is 1405) and top as 0.
6. Click ReszieIT 2's toolbar button.
7. Click the box shown with the number "1".
   • Expected (good) result: the window.screenY is 0 and the top of the window is not cut off.
   • Actual (bad) result: the window.screenY is negative and the top of the window is cut off.

The lines https://searchfox.org/mozilla-central/source/browser/components/extensions/parent/ext-windows.js#73-80 should be:

  params.left = Math.max(
    availLeft,
    Math.min(
      availLeft + availWidth - width,
      params.left
    )
  );
  params.top = Math.max(
    availTop,
    Math.min(
      availTop + availHeight - height,
      params.top
    )
  );

Comment 12

[YUKI "Piro" Hiroshi]

Attachment: Bug 1811326 - Place windows larger than screen inside screen always r?mixedpuppy

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:yuki, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit auto_nag documentation.

Comment 15

[Gregory Pappas [:gregp]]

IIRC check-in needed is supposed to be set as a tag on Phabricator, I don't know if any sheriffs still check the BMO one

Comment 16

[YUKI "Piro" Hiroshi]

Thanks, I forgot that...

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/aa406ef74561
Place windows larger than screen inside screen always r=willdurand

Comment 18

[Serban Stanca [:SerbanS]]

Backed out for causing mochitests failures in browser_ext_windows_update.js.

• Backout link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-FAIL | browser/components/extensions/test/browser/browser_ext_windows_update.js | window larger than available area of the screen is aligned at top-left of the screen - Got "0,23", expected "0,0"

For now, it seems only to fail on OS X 10.15 WebRender opt.