Closed Bug 343884 Opened 16 years ago Closed 16 years ago

Column order is not saved/reset on restart

Categories

(Core :: XUL, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: g.teunis, Assigned: neil)

References

Details

(Keywords: regression)

Attachments

(1 file, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060707 Minefield/3.0a1
Build Identifier: version 3 alpha 1 (20060707)

The column order of the main window is not saved correctly.

Reproducible: Always

Steps to Reproduce:
1. Open thunderbird
2. Reorder the columns like this: Read, Sender, Attachment, Subject, Date, Junk
3. Restart Thunderbird

Actual Results:  
Expect the same column layout before the exit.

Expected Results:  
Column order is changed in:
Attachment, Subject, Read, Sender, Junk, Date
I see this using Mozilla Sunbird too so it looks like a core problem.

Works in Sunbird 0.3a2+ (2006-07-02-06-trunk)
Fails in Sunbird 0.3a2+ (2006-07-03-06-trunk)
Assignee: mscott → Jan.Varga
Status: UNCONFIRMED → NEW
Component: Mail Window Front End → XP Toolkit/Widgets: Trees
Ever confirmed: true
Product: Thunderbird → Core
QA Contact: front-end → xptoolkit.trees
Version: unspecified → Trunk
Apparently Neil typo'd the bug number in the check-in comment. So bug 342072 would be the likely regressor.
Attached patch Possible patch (obsolete) — Splinter Review
Does this fix it for you?
(In reply to comment #4)
> Does this fix it for you?

No. I move the Junk column to before the Subject column, and on restart the Junk column is back after the Sender column. :-(

I'm using: Thunderbird version 3 alpha 1 (20060725)
Flags: blocking1.9a1?
*** Bug 345175 has been marked as a duplicate of this bug. ***
hi,

seeing the same issue/problem with:

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1b1) Gecko/20060806 BonEcho/2.0b1

column order simply won't 'stick' across restarts ...
*** Bug 347670 has been marked as a duplicate of this bug. ***
The preference mail.thread_columns_win  is not being changed when the 
column order is changed.  That might be relevant.
Keywords: regression
Changes made to mail.thread_columns_win in prefs.js (while mail trunk client is not running) have no effect whatsoever on the thread columns shown in the mail message list pane.  
Attached patch Proposed patch (obsolete) — Splinter Review
Assignee: Jan.Varga → neil
Attachment #228613 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #232539 - Flags: review?
Comment on attachment 232539 [details] [diff] [review]
Proposed patch

Bah, trigger-happiness on the Enter key :-(
Comment on attachment 232539 [details] [diff] [review]
Proposed patch

OK, so the first hunk is the important bit, I need to enumerate the columns in their current order, not the original order.

The second and third hunks are optional, I just thought it was strange that we should override nsIXULElement.idl here so I added 2 in a different way.

The fourth hunk exists because I was getting strict warnings.
Attachment #232539 - Flags: superreview?(jag)
Attachment #232539 - Flags: review?(enndeakin)
Attachment #232539 - Flags: review?
Comment on attachment 232539 [details] [diff] [review]
Proposed patch

>-              cols[i].ordinal += 2;
>+              cols[i].ordinal -= -2;

Is this just here as a sneaky way to do string to integer conversion?
Attachment #232539 - Flags: review?(enndeakin) → review+
Please add a comment why you're doing -= -2, or make the parseInt explicit.

What was the value of colindex that you were getting strict warnings for?
(In reply to comment #14)
>(From update of attachment 232539 [details] [diff] [review])
>>-              cols[i].ordinal += 2;
>>+              cols[i].ordinal -= -2;
>Is this just here as a sneaky way to do string to integer conversion?
Yes.

(In reply to comment #15)
>What was the value of colindex that you were getting strict warnings for?
Actually it was left over from attachment 228613 [details] [diff] [review] where I patched both cases
for consistency when in fact I was only getting warnings from the first case.
(In reply to comment #13)
>The fourth hunk exists because I was getting strict warnings.
OK, so this was bug 332797 all along... filed by me :-[
Two questions/issues:

1. Have we established which checkin (and for which bug) caused this regression?
I think we have to look at how it was reviewed.

2. What preference, if any, is now being used to establish the initial column
settings in the mail and news message list pane on startup?  

There has to be SOME workaround that will enable users to nail down the 
desired column order while waiting for this regression to be fixed!
What is it?
(In reply to comment #18)
>1. Have we established which checkin (and for which bug) caused this regression?
Yes, it was my checkin for bug 330236 (itself a regression from bug 212789).

>2. What preference, if any, is now being used to establish the initial column
>settings in the mail and news message list pane on startup?  
Unfortunately the current code always resets the column ordering.
Attached patch Core patchSplinter Review
Attachment #232539 - Attachment is obsolete: true
Attachment #233554 - Flags: superreview?(jag)
Attachment #232539 - Flags: superreview?(jag)
Attachment #233554 - Flags: superreview?(jag) → superreview+
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
On the current trunk build (version 3 alpha 1 (20060823)) the column order isn't saved correctly again.

When I move the Junk column to the last column, and restart. Then the Junk column is displayed before the date again.

Would you like me to file a new bug on that or reopen this one?
I have two PCs running different operating systems and they both seem to work correctly. Can you give me the link to the download you were using?
(In reply to comment #22)
Can't confirm, it works for me in Sunbird 0.3a2+ (2006-08-24-07-trunk).

(In reply to comment #23)
> I have two PCs running different operating systems and they both seem to work
> correctly. Can you give me the link to the download you were using?
> 

I use the trunk builds.
ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/thunderbird-3.0a1.en-US.linux-i686.tar.bz2
Currently using: version 3 alpha 1 (20060905)
Tried clean application, clean profile, no extensions etc.

When I order the columns in the following order, it doesn't seem to stick here.
Read, Sender, Attachment, Subject, Starred, Date, Size, Junk status
After restart, it displays
Read, Sender, Attachment, Subject, Starred, Junk status, Date, Size

So it seems the junk column is ALWAYS positioned before date.
I think I should file a new bug for this.
When I move the date column forwards (ie. third column), the junk column also moves in front of it on restart.
Aren't the column headings for mail supposed to be separately settable for
mail accounts and for news accounts, since they have different sets of 
column choices?  

I find that if I enable the display of "junk status", it becomes enabled for
all mail and news accounts, and likewise if I disable, it is disabled for all
mail and news accounts.  
(In reply to comment #26)
> When I move the date column forwards (ie. third column), the junk column also
> moves in front of it on restart.

I've filed a new bug for the junk column always being displayed before the date column after restart.
It's bug 351442

(In reply to comment #26)
>When I move the date column forwards (ie. third column), the junk column also
>moves in front of it on restart.
I don't see this happen in SeaMonkey (although I know you use Thunderbird, which might make a difference).
(In reply to comment #27)
>Aren't the column headings for mail supposed to be separately settable for
>mail accounts and for news accounts, since they have different sets of 
>column choices?
You might be thinking of the sender and recipient columns, which are separately settable when you're reading sent mail as opposed to received mail or news.
Well, mail has a column named "size"  which news doesn't have, 
  and news has a column named "lines" which mail doesn't have.
(In reply to comment #31)
> Well, mail has a column named "size"  which news doesn't have, 
>   and news has a column named "lines" which mail doesn't have.
That's another special case... news.show_size_in_lines enables that.
Blocks: 351442
Flags: blocking1.9a1?
Component: XP Toolkit/Widgets: Trees → XUL
QA Contact: xptoolkit.trees → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.