584586 - Thunderbird fails to remember window position

Status: RESOLVED DUPLICATE of bug 571439

(Thunderbird :: General, defect)

Description

[[e-mail]]

User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; GTB6.5; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C)
Build Identifier: Thunderbird 3.1.1

If I resize the main window by dragging a border and then exit and immediately re-open the program, the bottom of the window is in a lower posiiton than where I last set it. This lowering occurs whether I had changed the height or the width of the window.  If I don't change the H or W before closing, then the program will remember the window's last size and position. Apparently the X and Y posiitons are not written to a file after a change is made prior to closing (or it is not being read upon reopening).

Reproducible: Always

Steps to Reproduce:
1. Drag bottom border of program window to be even with top of a desktop shortcut icon.
2. Close program.
3. Reopen program and note that bottom border of program window is now lower than the top of the same desktop icon.
4. Check that similarly dragging a side border elicits the same window behavior.
Actual Results:  
The bottom border is lower than where it was before. 

Expected Results:  
Border should have been displayed in the same place as it was set when the program closed.

I didn't systematically bug test the window persistence of side or top borders, but I'd expect that if the window's X position either isn't being read or recorded, then maybe the same bug exists for the Y position. Or maybe the problem is with persistence of the window height and width.

This is not really as trivial as it may sound. It's also not minor since it should be quite easy to fix.  It's annoying when one is working with several other programs and wants Thunderbird to open exactly the way it was placed when it was closed. Thanks for considering this.

Comment 1

[Wayne Mery (:wsmwk)]

seems to me this should be a duplicate.
do you recognize this as matching one of the bugs in this list?
https://bugzilla.mozilla.org/buglist.cgi?chfieldto=Now&query_format=advanced&chfieldfrom=3y&list_id=1130306&short_desc=window%20position&short_desc_type=allwords&type0-0-0=nowords&value0-0-0=count%20counts&resolution=---&resolution=DUPLICATE&product=MailNews%20Core&product=Thunderbird

Comment 2

[[e-mail]]

Yes, others have reported that window persistence has been a problem - for a very long time. My report is pretty specific about what might lead to a fix, so I submitted it a year ago even though it may duplicate other reports. Maybe this bug gets ignored because people always maximize the window but I rarely do that.

Comment 3

[Wayne Mery (:wsmwk)]

I was rather hoping you'd identify a confirmed bug that matches, so we can link this to the bug where the actual work will be done.

Comment 4

[Jim]

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
This is a rather annoying bug. Window position is never saved. Window always opens to nearly full screen. I am on a fresh install of Windows 7 x64 SP1.

Comment 5

[Jim]

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4

AND

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100301 Eudora/3.0.1

I just wanted to mention, when I just switched from Eudora OSE 1.0 back to Eudora 8 Beta 9. I actually have both running using the same profile. Eudora 8  does not exhibit this problem at all. It also fixes my other major headache of the app starting in the "smart folder" setting. How on earth did such obvious bugs even make it to the first release of OSE?