Don't ignore xul window position on GTK.
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox157 | --- | fixed |
People
(Reporter: emilio, Assigned: emilio)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
Attachments
(1 external file)
| Assignee | ||
Comment 1•2 months ago
|
||
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?
| Assignee | ||
Comment 3•2 months ago
|
||
(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?
| Assignee | ||
Comment 5•2 months ago
|
||
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.
Comment 7•2 months ago
|
||
| bugherder | ||
Updated•1 month ago
|
Description
•