User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0 Build ID: 20160806094113 Steps to reproduce: I'm using Firefox on Arch Linux 64 bit with XFCE desktop. The XFCE panel (incl. the taskbar) is located at the top border of the screen (important !). For verifying that it's not add-on related, I've created a new, empty profile with no add-on's installed and only one setting changed: "When firefox starts: Show my tabs and windows from last time" I've opened a 3 windows, moved them to "cascaded" positions, closed and reopened Firefox. Actual results: All windows (except the one that already was at the top boder) were moved up by the same offset. Repeating the process of close / reopen moves them again, until all windows are at the top border. I've created two screenshots and merged them into one picture to illustrate this. As you can see, the offset matches the height of the XFCE panel (taskbar), so I think that it's just been forgotten when calculating the window positions. The issue occurs since the update to Firefox 48.0 and there was no XFCE update recently, so I think it's a Firefox issue, not a XFCE issue. The issue occurs on three PC's, one with sinlge-screen, two with dual-screen. On the PC's with dual screen, the XFCE panel is only on the left screen. So the available area for application windows starts at different Y positions on both screens. But windows on the right screen are also shifted after close / reopen. Additional info: I'm using multiple profiles. When opening a profile the first time since the Firefox update, all window positions are correct until I close / reopen it. So I think the issue occurs when saving the positinos, not when restoring them. Expected results: The windows should have been placed at the original positions.
here's regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bbb29a9b88dd680dbb59577cbe4dc6e58d117100&tochange=e3dcf062007e280ccf06e7bed7ff904d0fb44418 there are several bugs but only bug 1284687 patch was uplifted to 48.
mconley: looks like your patch regressed this? Seems mildly surprising to me; is there something weird with the timing of when we persist window coordinates? Making this fix-optional for a bit, as this is a minor issue that I'd suspect is Linux-only (and perhaps even specific to certain window managers?)
Hm, interesting. Would be good to know which platforms this affects. Hey RyanVM, would it be possible to get someone from SV to check this out and figure out if this affects OS X and Windows too? Might also be worth checking Ubuntu in the default configuration.
Flags: needinfo?(mconley) → needinfo?(ryanvm)
We are looking at this now Mike
Hello Mike, We tested on Win 8.1, Win 10, OS X 10.11, and Ubuntu 16.04 on all channels. This issue is reproducible on Ubuntu 16.04 on every channel. On Win 8.1, Win 10, and OS X 10.11, this issue is not reproduce.
Thank you! So I wonder if perhaps the GTK window code orders or arranges things a bit differently from the Windows / OS X backends when a window becomes invisible.
Order is an issue on a few platforms. I was going to write a new bug for that issue. The windows rearrange. Here is the pushlog https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=754b4805a65cab4f3aca99899227acc44ba4fb20&tochange=d8ce27c85590380ef025bb4ed66e564a4dff9bff
Great, thank you!
I just noticed that the window position is not only shifted upwards. It's also shifted to the left by 4 pixels. And there is another thing I noticed earlier (before this issue occurred the first time). But I'm not sure if it's related. If it is, it may help to complete the picture: When opening a Firefox profile with multiple windows (more than 4 or 5), it sometimes happens that one of the windows opens at a completely different place and then relocates itself to the target place after all windows are open. The "completely different place" appears to be determined by the window manager: It opens on the same screen where the mouse pointer currently is (I have a dual screen setup).
Mark 51 fix-optional as there are no actions for the moment but still happy to have the fix in 51.
Looks likely that this is going to be slipping another release :\
You need to log in before you can comment on or make changes to this bug.