Closed Bug 2070008 Opened 2 months ago Closed 2 months ago

Don't ignore xul window position on GTK.

Categories

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

defect

Tracking

()

RESOLVED FIXED
157 Branch
Tracking Status
firefox157 --- fixed

People

(Reporter: emilio, Assigned: emilio)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

Attachments

(1 external file)

No description provided.

This ifdef has been there basically since forever (bug 49802). But
session-restore will just call moveTo anyways as appropriate, and we
haven't seen major issues with that, so we should probably be fine.

Judging by the patch referenced in bug 1484378 comment 24, there are a few issues to be taken care of, for example CSD vs. SSD, restoring to 0,0, etc. Do you intend to address this elsewhere?

(In reply to Helge H. from comment #2)

Judging by the patch referenced in bug 1484378 comment 24, there are a few issues to be taken care of, for example CSD vs. SSD, restoring to 0,0, etc. Do you intend to address this elsewhere?

Those should work the same way session restore deals with it already, right?

Since the position was never restored, there are apparently some bugs:
https://searchfox.org/firefox-main/rev/c73b1b824216697b16d31c1d6fb57625d90f342c/xpfe/appshell/AppWindow.cpp#1194 and
https://searchfox.org/firefox-main/rev/c73b1b824216697b16d31c1d6fb57625d90f342c/widget/gtk/nsWindow.cpp#1101-1104
apparently prevent restoring to 0,0. The window is first created there unmapped and then not moved, so the WM puts it elsewhere. And there are pixel shifts depending on whether the title bar is drawn by the app (CSD) or the OS (SSD), at least there is such a setting in TB.
I'm just interpreting the patch that the downstream project is shipping. Have you tried those cases?

A lot of those changes seem incorrect to me and I'm pretty sure they'd fail tests. E.g. the CSD offset removal will for sure cause window.moveTo() to misbehave.

It is true that decorations are very annoying tho, as we get them async from the compositor so can't compute the right position we want until the window gets its first configure. I'm not claiming this patch will fix all those issues, which is why I spun off a separate bug. Let's do one thing at a time.

Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 157 Branch
Blocks: 2070464
No longer blocks: 2070464
Depends on: 2070464
Regressions: 2070958
QA Whiteboard: [qa-triage-done-c158/b157]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: