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
Previously fixed in bug https://bugzilla.mozilla.org/show_bug.cgi?id=405010
asking for blocking since this is a regression of a fixed blocking‑firefox3+ bug.
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
(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. >
I don't think we need to block on this, but it would be nice to have.
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 ?
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?
March nightly's here http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008/03/
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).
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.
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 ...)
the order is persisted, hidden state is not
Created attachment 319739 [details] [diff] [review] patch don't remove a persisted attribute
Comment on attachment 319739 [details] [diff] [review] patch r=me, thanks
Comment on attachment 319739 [details] [diff] [review] patch drivers: minor fix, minimum risk
Comment on attachment 319739 [details] [diff] [review] patch a1.9=beltzner
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
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
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
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
Could we add this to the following Litmus test? https://litmus.mozilla.org/show_test.cgi?id=4132
(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.
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