Open Bug 571439 Opened 16 years ago Updated 14 days ago

Thunderbird does not remember its window position

Categories

(Thunderbird :: Mail Window Front End, defect)

Product:
Thunderbird
Component:
Mail Window Front End
Platform:
All
Linux
Type:
defect

Tracking

(Not tracked)

People

(Reporter: wolfiR, Unassigned)

References

Details

If Thunderbird is opened under X11 (and is not fullscreen) it's always positioned at the left top corner instead of moving the position where it was closed. (Firefox is behaving like that: starts up and moves to the same position it was closed before)
Is there a similar difference for maximised versus non-maximised? AFAICT there's nothing obviously different between the xul files wrt persisting: http://mxr.mozilla.org/comm-central/source/mail/base/content/messenger.xul#76 http://mxr.mozilla.org/comm-central/source/mozilla/browser/base/content/browser.xul#90 but maybe digging into localstore.rdf might help to clarify things. The only other thing I've just noticed is that the 3-pane window and the standalone message window both have the same ids, so maybe that is confusing the persistence somehow.
Wolfgang, are you still seeing this in version 6 or newer?
Yes, a bit different though. With Thunderbird 6 it always opens with the previous size but in the middle of the screen instead of the position it was closed. Firefox 6 moves the window to the previous position instead.
This may be a different behavior, but it is appropriate to this bug's title. On a Mac (10.6.8), Thunderbird does not remember its window positions if those positions were on secondary screens. Upon restart, Thunderbird's windows will all appear on the primary screen.
April 10, 2014 Running Ubuntu Linux 13.10 Desktop (with Trinity); User Agent:Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 Firefox/28.0 Bug remains and remains annoying. I run Thunderbird and Firefox with a modified window size. If I minimize either and then restore it; it will restore to it's previous window position correctly. However, if I close both and then start both; Firefox restores to the window position it had before being closed. Thunderbird does not. Thunderbird restarts aligned to the left alongside the launchpad (sometimes left and top; sometimes left; always maintaining previous window size). It should restore to it's previous window position like Firefox and all other applications. This appears to be Thunderbird only problem ;) PS: I have not experienced this, but have seen mentioned; the problem reported for the Mac (comment 7/2/2012) concerning secondary screen also pertains to multiple work spaces in Ubuntu. Could be pertinent to this bug.
Set up a new machine today, just to notice I again need to write a script to fix Thunderbird's window position. Can't take much effort to fix this one. Could someone take a look? :(
My version 38.3.0 remembers its window position using Windows 8.1 on a 64-bit machine.
Hi, this bug is for the linux version.
I'm seeing the same issue as previous posters. I'm on Thunderbird 38.5.1 (Linux) on Arch. 1) Start TB, and move window somewhere on screen. 2) Shut it down and restart. 3) Observe that it always starts on top-left of left monitor (two monitor setup). It does seem to preserve window size at least, but not position.
Same here. Running Thuntherbird 45.5.0 on Debian Wheezy. New mail / reply / forward windows are always opened at the top left corner despite moving it into another position. Window size is respected, however.
I'm running into this problem, or at least a related one. I always run apps tiled side-by-side to 50% of the screen. (Usually, I have 2 Chrome windows open to 50% width, and then certain windows open on one or the other side of the screen, always perfectly edge-aligned). This works for Chrome, Telegram, Spotify, Skype, Steam, Nautilus... But with Thunderbird, the size is persisting, it being fully maximised vertically and horizontally at 50% screen width, but it opens around 54 pixels away from the left edge of the screen, rather than snapped-to the left, as I want it. I seem to recall having this problem on my previous install, but don't know how I fixed it there, either. - Ubuntu GNOME 17.04 - GNOME Shell 3.24.2 - Linux 4.10.28-generic

@atmarsden96 Seeing this issue as well on Windows 10 with Thunderbird 60.5.0 (32-bit).

In xulstore.json there are "screenX" and "screenY" values. It seem that if screenX is set to a negative value, i.e. the Thunderbird window is off the left-hand side of the screen, then screenX is set to "0" on restarting.

Snapping the window to the left-hand edge appears to have a screenX value of "-6" with my setup, so after doing this and restarting Thunderbird screenX is reset to 0 which results in the Thunderbird window being a bit away from the left-edge of the screen.

You can observe this happening by keeping open xulstore,json and watching the values change as Thunderbird restarted.

(In reply to Stephen from comment #13)

@atmarsden96

Should be @atmarsden95

Severity: normal → S3

Does this still reproduce?

Flags: needinfo?(spl1972)
Flags: needinfo?(noelamac)
Flags: needinfo?(chriechers)

(In reply to Wayne Mery (:wsmwk) from comment #15)

Does this still reproduce?

Yes, at least for me.
(now currently running TB 140.7.0esr)

Flags: needinfo?(noelamac)

Running openSUSE Linux Tumbleweed with Wayland, and Gnome 49.
Thunderbird is v147.0.
Thunderbird always opens in the middle of the screen, but doesn't remember the last screen position upon restart.
It remembers the size of the window though.

Flags: needinfo?(chriechers)

Yes, v146 on Fedora 43 X11. Always starts in top left corner, hardcoded near (100, 100).

(Note: apps on Wayland cannot set window position, a new security req. The window manager should/is handling it in that case.)

Still reproducible in Thunderbird 154.0 (Flathub, org.mozilla.thunderbird) on Linux Mint 22.2,
Cinnamon 6.6.4 / Muffin 6.6.1, X11, GTK 3.24.41, single 3440x1440 monitor.

Measurements that may narrow this down: the position IS persisted correctly, it is the
restore that never reaches the window manager, because the main window ships no position
hint at all.

  1. Saving works. After dragging the main window flush to the left edge, xulstore.json holds:

    "messengerWindow": {"screenX":"0","screenY":"0","width":"1720","height":"1372","sizemode":"normal"}

    which matches xwininfo (frame at 0,0).

  2. Restore does not. Closing and relaunching with that exact xulstore always yields
    absolute frame x=50, regardless of the stored value. Overwriting screenX/screenY with
    400/300 while Thunderbird was closed changed nothing: the window still came up at x=50,
    with y stepping through a cascade (28, 78, ...) on successive launches. Width and height
    are restored exactly, every time.

  3. The main window sets no position hint:

    $ xprop -id <messengerWindow> WM_NORMAL_HINTS
    WM_NORMAL_HINTS(WM_SIZE_HINTS):
    program specified minimum size: 95 by 95
    program specified maximum size: 16384 by 16356
    program specified base size: 95 by 95
    window gravity: NorthWest

    No "program specified location" / "user specified location" line, i.e. neither PPosition
    nor USPosition. Mutter/Muffin only skips its own placement for windows that set one of
    those flags, so every launch gets auto-placed by the cascade and the restored coordinates
    are discarded. Checking every other client in the same session (Brave, Teams, PhpStorm,
    Bitwarden, Double Commander) shows they all set the flag - and they all restore their
    position correctly under the same window manager. This lines up with the earlier comment
    in this bug quoting the window manager log line "PLACEMENT: Not placing window with
    PPosition or USPosition set" for the application that worked.

Separate but related, and possibly why some reporters describe the window "walking" across
the screen over many restarts: with the default mail.tabs.drawInTitlebar=true the persisted
screenX/screenY include the invisible GTK CSD shadow margins. _GTK_FRAME_EXTENTS on this
system is 20,20,20,20 for the unfocused window and 26,26,23,29 for the focused one, so the
value written on shutdown depends on focus state, and a window parked at x=0 is stored as
screenX=-20. Setting mail.tabs.drawInTitlebar=false makes _NET_FRAME_EXTENTS take over and
the stored numbers become stable - but the position is still ignored on restore, per point 3.

Is it still the case that Firefox does not have this problem?

Flags: needinfo?(spl1972)
You need to log in before you can comment on or make changes to this bug.