432454 - Library columns hidden state is not persisted

Status: VERIFIED FIXED

(Firefox :: Bookmarks & History, defect, P3)

Description

[Jim Jeffery not reading bug-mail 1/2/11]

Open the Library and using 'View' add some columns to your right pane. 
Close/restart Minefield and your changes are lost.  

The changes will persist as long as you have the session up, but once you close the application, the changes are lost. 

This was fixed previously from what I recall. 

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008050606 Minefield/3.0pre Firefox/3.0 ID:2008050606

Comment 1

[Jim Jeffery not reading bug-mail 1/2/11]

Previously fixed in bug https://bugzilla.mozilla.org/show_bug.cgi?id=405010

Comment 2

[(mostly gone) XtC4UaLL [:xtc4uall]]

asking for blocking since this is a regression of a fixed blocking‑firefox3+ bug.

Comment 3

[Jim Jeffery not reading bug-mail 1/2/11]

I need help finding the regress range.  I have run out of time for today.

OK in the 5-1 nightly 
Broke in the 5-3 nightly 

Comment 4

[Jim Jeffery not reading bug-mail 1/2/11]

(In reply to comment #3)
> I need help finding the regress range.  I have run out of time for today.
> 
> OK in the 5-1 nightly 
> Broke in the 5-3 nightly 


EDIT: still broken in teh 5-1 nightly,  will stick the settings for only 1-time of opening/closing the Library, which is slightly different than losing settings when closing the application.


> 

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

I don't think we need to block on this, but it would be nice to have.

Comment 6

[Jim Jeffery not reading bug-mail 1/2/11]

Been reported in the forums that its broken in 3/20 builds also.  This was fixed not long before that date - or was it really ?  

Comment 7

[Luke Iliffe (Harlequin99)]

The oldest 2008 build I can find on ftp.mozilla.org is the nightly build 2008-04-08-05. In this build the columns persist across 1 restart of firefox only. Once the 2nd restart the column changes are gone. There was no point going back into 2007 as bug 405010 was resolved fixed on 2008-03-08. 

Anybody know where I can find March builds?

Comment 8

[Jim Jeffery not reading bug-mail 1/2/11]

March nightly's here
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008/03/

Comment 9

[tekstr1der]

I originally brought this up in the builds forum. When 405010 was checked in, I
only tested with one restart of Minefield. For some reason, I was under the
impression that my nightly updating was resetting the defaults as I have
repeatedly reset the columns to the way I desire since then. I fear the regress
range goes all the way back to the check-in (if it was ever properly fixed).

Comment 10

[Luke Iliffe (Harlequin99)]

I can confirm comment 9. I checked the 2008030706 build and column changes did not persist across any restarts. The following nightly 2008030806 column changes persisted across 1 restart only. This behaviour persists right up to todays nightly on a new profile. This implies the original checkin of bug 405010 on 20080308 only ever fixed it for 1 restart.

Comment 11

[(mostly gone) XtC4UaLL [:xtc4uall]]

sorry Mike, but it's hardly understandable for me that this one does not get a blocking+.
Bug 405010 is blocking+ and supposed to fix the problem described in my STRs. if we now get to know that it hasn't been fixed in that way either this one deserves a '+' or the other bug should be reopened with keeping its blocking+.
either way the issue should be fixed before the Fx3 rel concerning Fx2-parity (which has been dropped often in other places ...)

Comment 12

[Marco Bonardo [:mak]]

the order is persisted, hidden state is not

Comment 13

[Marco Bonardo [:mak]]

Attachment: patch

don't remove a persisted attribute

Comment 14

[Dietrich Ayala (:dietrich)]

Comment on attachment 319739 [details] [diff] [review]
patch

r=me, thanks

Comment 15

[Marco Bonardo [:mak]]

Comment on attachment 319739 [details] [diff] [review]
patch

drivers: minor fix, minimum risk

Comment 16

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 319739 [details] [diff] [review]
patch

a1.9=beltzner

Comment 17

[Dietrich Ayala (:dietrich)]

Checking in browser/components/places/content/places.js;
/cvsroot/mozilla/browser/components/places/content/places.js,v  <--  places.js
new revision: 1.167; previous revision: 1.166
done

Comment 18

[Jim Jeffery not reading bug-mail 1/2/11]

Fixed using Vista HP SP1 and build:

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008050804 Minefield/3.0pre Firefox/3.0 ID:2008050804

Comment 19

[Luke Iliffe (Harlequin99)]

Fixed in XP SP3 and build:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008050804 Minefield/3.0pre

Comment 20

[(mostly gone) XtC4UaLL [:xtc4uall]]

thanks again Marco :)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008050806 Firefox/3.0.0 ID:2008050806

Comment 21

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Could we add this to the following Litmus test?

https://litmus.mozilla.org/show_test.cgi?id=4132

Comment 22

[Tracy Walker [:tracy]]

(In reply to comment #21)
> Could we add this to the following Litmus test?
> 
> https://litmus.mozilla.org/show_test.cgi?id=4132
>
Yep, done. 

Comment 23

[Gervase Markham [:gerv]]

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv