1844674 - [ResizeIT 2 addon] Programmatic positioning no longer positions correctly.

Status: VERIFIED FIXED

(Core :: Widget: Gtk, defect, P3)

Description

[Adam]

Starting with version 115 the add-on ResizeIT 2 (https://addons.mozilla.org/en-US/firefox/addon/resizeit-2/) wasn't positioning the windows where specified, but offset down/right from their requested positions. And when I tried manually using Javascript, I also couldn't move the window all the way to the left like before. I'm using mutter/X11.

Using mozregression, it tracked the change to Bug 1651463. Using the add-on, by opening its preferences and enabling the top one to position to (0,0), then clicking the add-on and selecting the "1" button, it moves the window to the top-left before that commit and leaves a gap on both edges on builds following that commit. Similarly, if I open the add-on tab (or another privileged tab) and use the console to window.moveTo(0,0), in builds before that, the window would hug the left edge of the screen as expected. On later builds it leaves a gap along the left edge of the screen.

For whatever reason, moveTo() does move the window to the top (touching the Gnome Shell bar) on post-regression builds, where the add-on cannot. The add-on uses windows.update() from the extensions API with a state object to make its changes to size and position, possibly accounting for that difference.

On starting the browser, the position is correctly restored, even if that is a position I can no longer move the window to with window.moveTo() or the add-on.

Comment 1

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

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

:emilio, since you are the author of the regressor, bug 1651463, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

This extensions code: https://searchfox.org/mozilla-central/rev/d35b3fe3d8230a255b988afb0ebda1176fc2f50b/browser/components/extensions/parent/ext-windows.js#69-76

Probably needs a fix like https://phabricator.services.mozilla.com/D179111 to not clamp too much.

I'm not sure I'll have a lot of time to work on this so please be my guest if someone wants to submit a patch.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1844674 - Account for screen slop when calculating available top/left in extension window apis. r=#extension-reviewers

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0c00a089b536
Account for screen slop when calculating available top/left in extension window apis. r=extension-reviewers,robwu

Comment 5

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/0c00a089b536

Comment 6

[Adam]

Using the extension with the nightly build still leaves the gap on the left edge. It [appeared to fix] letting the window move to the top edge.

After some manual testing in Javascript console, it looks like it needs to offset params.left by removing the slop (and same for vertical). A request for 0, 0 should be translated to -window.screenEdgeSlopX, -window.screenEdgeSlopY.

At https://hg.mozilla.org/integration/autoland/file/0c00a089b5360c28d9a17d24257472ffdb089498/browser/components/extensions/parent/ext-windows.js#l71 it checks Math.max(availLeft[≈-23, but actually =0], params.left[=0, but actually ≈23]) and picks params.left. The nominal values are wrong because the params.left hasn't been adjusted. Same thing happens on vertical, but Gnome Shell's top bar was hiding that fact.

I think it should be: Math.max(availLeft, params.left - slopX) (and similar for vertical). Removing the slop from the request puts it in the correct translation, while the avail* terms serve as fallback for sanity, in case the request is invalid.

Comment 7

[Emilio Cobos Álvarez (:emilio)]

No, the code is correct. The screenX of the window is -23, -23, so you should configure the extension to move there instead of 0,0. That is, Params.left should not be zero. I thought of special casing move requests to translate by the client offsets in the past and it was super messy so I'd rather not.

Comment 8

[Adam]

I failed to understand that it was an expected change in behavior, but it'll be easy to adjust to. Thank you.

Comment 9

[Dianna Smith [:diannaS]]

:emilio are you planning on requesting an uplift before RC tomorrow? if not, please set 116 to wontfix. Ty!

Comment 10

[Emilio Cobos Álvarez (:emilio)]

Comment on attachment 9345078 [details]
Bug 1844674 - Account for screen slop when calculating available top/left in extension window apis. r=#extension-reviewers

Beta/Release Uplift Approval Request

• User impact if declined: Extensions on Linux/x11 might not position themselves properly.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Comment 0
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Simple follow up change to the regressing bug.
• String changes made/needed: none
• Is Android affected?: No

Comment 11

[Dianna Smith [:diannaS]]

Comment on attachment 9345078 [details]
Bug 1844674 - Account for screen slop when calculating available top/left in extension window apis. r=#extension-reviewers

Approved for 116.0rc1

Comment 12

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/23b1fabe6e02

Comment 13

[Dianna Smith [:diannaS]]

Comment on attachment 9345078 [details]
Bug 1844674 - Account for screen slop when calculating available top/left in extension window apis. r=#extension-reviewers

Approved for 115.1esr

Comment 14

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/1a95a0b7dffa

Comment 15

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Hello! I reproduced the issue with Firefox 117.0a1 (2023-07-20) on Ubuntu 20.04.6 LTS X11 by following the next STR:

1. Installed Resizeit 2 addon and set 0-0 for Position: Enable /Left /Top for the first shortcut.
2. Checked and used the first Shortcut (default Ctrl + 1) to position the window on the top and left corner.
   Actual Result: The window position will leave a gap between the top and left bars.

I can no longer see the issue with Firefox 117.0a1 (2023-07-24), Firefox 116.0b9 (2023072400848) and Firefox 115.1esr (2023072411320) treeherder builds on Ubuntu 20.04.6 X11. Setting 0-0 Position: Enable / Left / Top inside the addon and using the shortcut will move Firefox to the top and left side of the screen near the Menu bar and Gnome bar without leaving any gap between them.