1296922 - Windows positions shifted up after restart

Status: NEW

(Firefox :: Session Restore, defect)

Description

[Markus.N]

Attachment: Firefox_window_positions_shifted.png

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.

Comment 1

[Tooru Fujisawa [:arai]]

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.

Comment 2

[Justin Dolske [:Dolske]]

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?)

Comment 3

[Mike Conley (:mconley) (:⚙️)]

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.

Comment 4

[Justin [:JW_SoftvisionQA]]

We are looking at this now Mike

Comment 5

[Justin [:JW_SoftvisionQA]]

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.

Comment 6

[Mike Conley (:mconley) (:⚙️)]

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.

Comment 7

[Justin [:JW_SoftvisionQA]]

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

Comment 8

[Mike Conley (:mconley) (:⚙️)]

Great, thank you!

Comment 9

[Markus.N]

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).

Comment 10

[Gerry Chang [:gchang]]

Mark 51 fix-optional as there are no actions for the moment but still happy to have the fix in 51.

Comment 11

[Ryan VanderMeulen [:RyanVM]]

Looks likely that this is going to be slipping another release :\

Comment 13

[Markus.N]

It's getting worse ... now some windows shift, others open at their original place.

As long as all windows had the same behavior, I could use my xautomation (xte) script to correct the positions after starting Firefox. But this script depends on knowing the exact positions, therefore it can not work anymore with window random positions. Making a screenshot for every single window and then using visgrep to find its position would be way too slow.

And even if I could get this working with random positions, there is a limited time left ... once XFCE switches from xorg to wayland, xte will stop working at all.

Are there any plans to fix this bug ?

Comment 14

[Vincent Lefevre]

I use FVWM2 under Debian/unstable, and this issue still occurs with FF 104.0.2. The window is actually shifted up and to the left. Here are the successive (X,Y) positions of the window after each restart:

(1500,700)
(1492,644)
(1484,589)
(1477,533)
(1469,478)
(1462,422)

So the X delta is either −7 or −8, and the Y delta is either −55 or −56.

Comment 15

[Vincent Lefevre]

Note that there is additional information in bug 1374253 (for a much older FF version than now, but the issue appears to be the same). In particular, the delta still seems to correspond to

• X: 2 × left border
• Y: 2 × (top border + title bar)

except that this is now approximate.

Comment 16

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

The severity field for this bug is relatively low, S3. However, the bug has 21 votes.
:dao, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 17

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.