Matthias Bockelkamp Reporter
	Description • 18 years ago

Every time i start MailNews, the junk column is reset to it's default place. I'd expect it to show up where i dropped it before.

	Nelson Bolyard (seldom reads bugmail)
	Comment 1 • 18 years ago

I see this every time I restart Gecko/2007062001 SeaMonkey/2.0a1pre

	WADA:World Anti-bad-Duping Agency
	Comment 2 • 18 years ago

FYI.
No problem when; (on MS Win-XP).
 Tb 2.0.0.4 release build, Tb trunk 6/23 build, and Seamonkey 1.1.2 release build.
In any case, position of "Junk Staus" in column name list(drop down menu of icon at right most column header, icon above vertical scroll bar of thread pane) was properly changed accordig to position change of "Junk Status" column header.

	Nelson Bolyard (seldom reads bugmail)
	Comment 3 • 18 years ago

Fully reproducible in Gecko/2007070201 SeaMonkey/2.0a1pre

I set the order to: 
thread, attachments, subject, read, flag, from, Date, status, Junk Status, 
Unread in Thread, Total in Thread, Size

After restart, the Junk Status is moved to the 4th column, between Subject
and Read

	Sven Grull
	Comment 4 • 17 years ago

Seems that TB is also affected, see bug 351442. 

	WADA:World Anti-bad-Duping Agency
	Comment 5 • 17 years ago

Someone says problem persists, but someone says worksforme.
Depends on Theme(Classic or Modern), Layout(Classic/Wide/Vertical)?
I use Theme=Modern and Layout=Wide when Seamonkey 1.x and Layout=Wide when Tb(2.0/trunk), and was WORKSFORME as I said in comment #2.

Note: At least Bug 389735 exists on Tb trunk when Vertical layout.

	Sven Grull
	Comment 6 • 17 years ago

I can still reproduce this bug with SM trunk build 20070728 with both themes and each layout.

	Nelson Bolyard (seldom reads bugmail)
	Comment 7 • 17 years ago

Several people experience this daily on the trunk, and have done so since
2.0a1pre came out.  It is also a problem in thunderbird, which stronly 
implies it is in code common to both.

	WADA:World Anti-bad-Duping Agency
	Comment 8 • 17 years ago

(In reply to comment #7)
> Several people experience this daily on the trunk

Is problem re-produced with new profile(and a dummy POP3 account of No Global Inbox)?
Is problem re-produced with clean panacea.dat and/or localstore.rdf?
(1) Keep back up of current profile directory
(2-A) Delete panacea.dat and/or (2-B) Delete localstore.rdf
(3) Restart Seamonkey or Thunderbird, and change column order
(I frequently deleted panacea.dat to remove garbages by test.)
(It may be a reason why I can't re-produce problem.          )

	Nelson Bolyard (seldom reads bugmail)
	Comment 9 • 17 years ago

Using Gecko/200708100202 SeaMonkey/2.0a1pre,
The problem is easily reproduced in a new profile with a dummy pop3 account 
and no global inbox.  

The problem is easily reproduced in an older account where the panacea.dat
and localstore.rdf files have been removed.  

I enable numerous columns that are not enabled by default, and disable one
column that is enabled by default, and then reorder the columns to be:

thread, attachments, subject, read, flag, from, Date, status, Junk Status, \
Unread in Thread, Total in Thread, Size

After restart, the columns are ALWAYS changed to this order:
thread, attachments, subject, Junk Status, from, read, flag, Date, status, \
Unread in Thread, Total in Thread, Size

Notice that "read", "flag", and "Junk Status" have all been moved from 
where I put them.  I believe they have reverted to their default positions.

	Nelson Bolyard (seldom reads bugmail)
	Comment 10 • 17 years ago

I should add this observation.  If the Junk Status column is disabled,
then the positions of other enabled columns are not forgotten at restart.
If Junk Status is enabled, then several column's positions are forgotten
or reset upon restart.

	WADA:World Anti-bad-Duping Agency
	Comment 11 • 17 years ago

(In reply to comment #9)
> The problem is easily reproduced in a new profile with a dummy pop3 account 
> and no global inbox.  

I could observe problem for a while with new profile at last, but during test, problem disappeared... (Seamonkey trunk 2007/8/11,Win-XP)
(1) New profile, a dummy POP3 account (no change of prefs settings)
(2) When initial column choice and column order, I could observe problem.
    - Move Junk column, and restart mail&news only
      => Junk column was moved back to just right to Subject column
         (This seems to be problem of original bug report of comment #0)
    - Move Date(or From) column between Subject and Junk, and restart mail&news
      => Junk moved back to just right to Subject column,
         and Date(or From) was also moved back to original position
         (This looks to be similar phenomenon to yours)
    Above were also true after several clicking of "Reset Column Ordering"
(3) After all column are chosen(order is not changed), I could observe same phenomena as (2) for a while(I moved positon of other than Date/From). But when I moved position of Junk column and some column's randomly, problem suddenly disappeared, and I couldn't reproduce problem any more, even after click of "Reset Column Ordering".
I tried (1) thru (3) twice, and result was almost same.
Sorry but I can't find what column(or column combination) killed the problem yet.
    

	Mark Banner (:standard8) Assignee
	Comment 12 • 17 years ago

This is a possible fix for this problem. I believe the problem comes down to the fact that UpgradeThreadPaneUI is typically throwing an error during its run. This means that mailnews.ui.threadpane.version isn't being set at the end of the function. So every time the mailnews window is opened, it goes through at least some of the UpgradeThreadPaneUI function and reorders some of the columns.

For those with this problem, setting mailnews.ui.threadpane.version to 5 should be a work around till we get a proper fix in.

Neil, can you take a look at this please?

The problem appears to be that the _reorderColumn function in the tree.xml file (which is the same as the xpfe one AFAICT) doesn't seem to like being called where one column is already before/after another column (it says that cols[0] isn't a valid property). Which is strange, as the ordinals seem to fit correctly (each individual column and individual separator have their own ordinal value).

This patch is a workaround whereby we don't do the reorder if its not necessary. I just couldn't work out if _reorderColumn is behaving correctly, or what was actually going wrong with it.

	neil@parkwaycc.co.uk
	Comment 13 • 17 years ago

Comment on attachment 276691 [details] [diff] [review]
Possible fix

No, I don't think this is right. Firstly, any bug with tree.xml should be fixed there, not worked around here. Secondly, the problem is because we don't migrate localstore.rdf so the columns are in fact already in the correct order and don't need to be upgraded. We should therefore remove all the upgrading code (in all modules) and also update the default values of the prefs in case we need to add upgrade code to match appropriate changes in Thunderbird.

	WADA:World Anti-bad-Duping Agency
	Comment 14 • 17 years ago

(In reply to comment #12)
> For those with this problem, setting mailnews.ui.threadpane.version to 5 should
> be a work around till we get a proper fix in.

mailnews.ui.threadpane.version=5 was workaround.
(0) Seamonkey trunk 2007/8/11 build, New profile, a dummy POP3 account
    Initlal(default) column choice, initial(default) column order
    Test: Move Junk column by Drga&Drop
(1) mailnews.ui.threadpane.version=1 (initial value when profile creation)
    => problem occurred (Junk was moved back to just right of Subject column)
(2) Change to mailnews.ui.threadpane.version=5
    => problem didn't occur
(3) Reset to mailnews.ui.threadpane.version=1
    => problem occurred again

	Nelson Bolyard (seldom reads bugmail)
	Comment 15 • 17 years ago

Neil, You seem to be saying this is a profile migration problem, but 
this behavior is seen in brand new never-migrated SM 2.0a1pre profiles. 

	WADA:World Anti-bad-Duping Agency
	Comment 16 • 17 years ago

FYI.
When first start up after new profile creation, Tb 2.0.0.6 generated mailnews.ui.threadpane.version=5 in prefs.js, but Thunderbird trunk and Seamonkey trunk didn't generate mailnews.ui.threadpane.version line (thus mailnews.ui.threadpane.version=1=default initially). This was the reason why trunk only problem.    

	neil@parkwaycc.co.uk
	Comment 17 • 17 years ago

Actually, looking at the code more closely, it seems to be a problem with new profiles on any trunk builds, not just toolkit ones. The branch code sort of works with new profiles (i.e. there's no exception), so nobody notices.

The issue with the code as it stands is that it assumes that if the version is 1 then the columns are in the incorrect order. Fixing bug 392653 would of course fix this, since it would then not matter. Simply appending new columns and relying on the the upgrade code to order columns would also have fixed this.

We still don't currently need any upgrade code on trunk though!

	Mark Banner (:standard8) Assignee
	Comment 18 • 17 years ago

I don't think we can really remove thunderbird's upgrade, so this patch keeps things the same for them, and just removes the redundant thread pane upgrade for us.

	Mark Banner (:standard8) Assignee
	Comment 19 • 17 years ago

Patch checked in -> fixed.

	WADA:World Anti-bad-Duping Agency
	Comment 20 • 17 years ago

With Thunderbird version 3.0a1pre (2007090515) (MS Win-XP SP2)
 a) New profile   : mailnews.ui.threadpane.version=6
 b) Existent prof : mailnews.ui.threadpane.version was changed to 6
In both cases, changed Junk column position was kept after restart.
=> VERIFIED

 

	Matthias Bockelkamp Reporter
	Comment 21 • 17 years ago

still works :)