794749 - All resizable/movable windows in email should remember user selected size/position

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Alexander Kogan]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0.1
Build ID: 20120905151427

Steps to reproduce:

Tried to resize columns in the seamonkey email


Actual results:

after I closed and reopened seamonkey, all columns were at their default size


Expected results:

it should remember / save my resize changes

Comment 1

[Philip Chee]

I thought they did. When did this break do you remember? Try disabling all  your addons via Tools->Addons->Extensions and restarting SeaMonkey. A misbehaving extension might be intefering.

Comment 2

[Alexander Kogan]

(In reply to Philip Chee from comment #1)
> I thought they did. When did this break do you remember? Try disabling all 
> your addons via Tools->Addons->Extensions and restarting SeaMonkey. A
> misbehaving extension might be intefering.

Hello, thanks alot.
I deactivated all addons I have - same result.
My windows got the 3 columns view. When I try to resize the boarder in the middle, so after a restart - everything is an their default positions.... damn :)

Comment 3

[rsx11m]

Neither dataloss (in terms of messages) nor a crash, thus not a "critical" bug.
This may be a duplicate of Thunderbird bug 710056 though, thus may work again properly once the fix there is checked in on the beta channel and the next 2.13 beta (likely not the one to be released tomorrow) comes out. Let's not declare this a duplicate just yet though unless it can be verified fixed in that build.

Comment 4

[rsx11m]

(In reply to Alexander Kogan from comment #2)
> My windows got the 3 columns view. When I try to resize the boarder in the
> middle, so after a restart - everything is an their default positions....

So, that affects only the columns in the message view or the size of /any/ window whatsoever? The latter may point to a corrupt localstore.rdf file.

http://kb.mozillazine.org/Corrupt_localstore.rdf

Comment 5

[Alexander Kogan]

No, its more https://bugzilla.mozilla.org/show_bug.cgi?id=550286

Comment 6

[rsx11m]

Ok, based on bug 550286 comment #24 it appears rather unlikely that this issue relates to bug 710056 given that the column-width handling is different and not kept in the .msf summary files for each folder separately.

Thus I'd assume some localstore.rdf issue as the most probable cause. Shut down SeaMonkey and go into the profile folder, which you can locate as described in http://kb.mozillazine.org/Profile_folder_-_SeaMonkey#For_Windows_users

There, rename localstore.rdf, e.g., to localstore.backup and restart SeaMonkey (this will reset all custom sizes and widths, creating a new localstore.rdf from scratch). If changing the column widths persists now through a restart, the old file was somehow corrupted. If nothing changes, shut down SM again and delete the new localstore.rdf file, renaming back localstore.backup to restore your old settings.

Comment 7

[rsx11m]

Alexander, did creating a new localstore.rdf file from scratch resolve the issue?

Comment 8

[Alexander Kogan]

(In reply to rsx11m from comment #7)
> Alexander, did creating a new localstore.rdf file from scratch resolve the
> issue?

Nope, I'm sorry.
renaming the localstore.rdf just reseted all my "seeing" settings, but the problem with the columns still exists.

Tried it on over 10 PCs, this problem is definitely not binded on a special machine.
....
Is it working by someone? What  is happening, if you just make the "3 columns view" (not the view with the reading part at the bottom) and try to resize them?

thanks.

Comment 9

[rsx11m]

I'm unable to reproduce this on a current 2.14a2 (Windows 7) nightly, but maybe I did not follow your steps exactly enough. Here is what I've tried:

 - resized the "Subject" column in the Inbox view (IMAP)
 - restarted SeaMonkey, column widths persisted
 - in Folder Properties, ran "Repair Folder" (bug 550286)
 - restarted SeaMonkey, column widths persisted
 - changed "Subject" column width back to previous
 - restarted SeaMonkey, column widths persisted

Comment 10

[Flex]

Same problem here.

I figured out that it might depend on the layout type you chose. When I chose "layout - vertical view" I had the same problem. Since you wrote about "the middle bar", I guess you had the vertical layout too.

I had no problem when I changed to classical view or standard view ("klassische ansicht", not sure how it is named in the English version).

So it seems that just in vertical view Seamonkey won't remember the positions of the seperators in the E-Mail-Window.

Comment 11

[Philip Chee]

> So it seems that just in vertical view Seamonkey won't remember the positions of the
> seperators in the E-Mail-Window.
Good clue. Thanks.

Comment 12

[[e-mail]]

It looks like I put the persist attributes in the wrong place in bug 105542.

The minwidth, width and persist on threadTree have no effect, as it's not a sibling of the splitter. Instead they belong on messagesBox, assuming that doesn't break the other layouts.

We may want to tweak the widths and also the messagesBox's flex for an optimum default appearance in wide view, but in this case we should be careful because UpdateFolderPaneFlex also updates messagesBox's flex.

Comment 13

[[e-mail]]

Attachment: Proposed patch

This fixes the vertical view case by moving the bogus attributes from the thread tree to the correct box.

I used the same widths and flex as this gives the message pane the same default priority as it does in the horizontal views.

Comment 14

[Flex]

This bug is still existing in 2.26 beta2 although it was already reported in the IRC channel that someone fixed this.

Comment 15

[Tony Mechelynck [:tonymec]]

(In reply to Martin from comment #14)
> This bug is still existing in 2.26 beta2 although it was already reported in
> the IRC channel that someone fixed this.

Apparently Neil has "written a fix" for it, see comment #13. I expect the fix (when and if it gets review+ by Mnyromyr) to be checked-in first on Trunk, which ATM would be 2.29a1 (or some later version if there is a trunk → aurora train in the meantime). Once the fix is checked in on trunk the bug will be marked RESOLVED FIXED. Then the fix may or may not get "approved" for porting to other branches (e.g. from 2.29a1 trunk to 2.28a2 aurora and possibly 2.27 beta; I don't expect it to trigger a 2.26.1 release). Porting the fix from one branch to, well, the previous one ;-) should be tracked by means of the "tracking flags" near top right of this page.

And, developers, sorry for rehashing what you all know but IMHO polite beginners deserve a bit of explanation from time to time even if this isn't the proper place to do it.

Comment 16

[Ian Neal]

Comment on attachment 8368458 [details] [diff] [review]
Proposed patch

[Triage Comment]
a/r=me

Comment 17

[[e-mail]]

Pushed comm-central changeset 9bd77606066e.

Comment 18

[[e-mail]]

https://hg.mozilla.org/releases/comm-beta/rev/00b09bc2d0ea

Comment 19

[[e-mail]]

https://hg.mozilla.org/releases/comm-aurora/rev/f4dd28fcd93c

Comment 20

[Justin Wood (:Callek)]

Pushing to comm-release for SeaMonkey 2.26.1

$ hg tip
changeset:   20172:27995f4797f5
branch:      SEA_2_26_1_RELBRANCH
tag:         tip
user:        Neil Rashbrook <[e-mail]>
date:        Mon Jun 02 00:09:18 2014 +0100
summary:     Bug 794749 Vertical view doesn't persist splitter positions correctly r=IanN a=IanN

Comment 21

[Karsten Düsterloh]

Comment on attachment 8368458 [details] [diff] [review]
Proposed patch

(Removing obsoleted r?)