419315 - All bookmarks lost after using "Restore all user preferences"

Status: VERIFIED FIXED

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

Description

[Emil Ivanov]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008022404 Minefield/3.0b4pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008022404 Minefield/3.0b4pre

When the setting to restore all user preferences is used, all bookmarks and folders are erased, except the default folders/bookmarks.

Reproducible: Always

Steps to Reproduce:
1. Import/add bookmarks
2. Verify they are imported/added
3. Restart in Safe Mode and use "Reset all user preferences to Minefield defaults"

Comment 1

[Ria Klaassen (not reading all bugmail)]

Confirmed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008022400 Minefield/3.0b4pre

Comment 2

[Ria Klaassen (not reading all bugmail)]

Problem is that I can't always reproduce this. Little differences in installation locations seem to decide if the bug happens or not. I see the problem already in a 1 Oct 2007 build and maybe earlier. It's the oldest I tried because it hung terribly while starting up after making changes.

Comment 3

[Steve]

Assuming modules/libpref/src/prefapi.cpp -> PREF_ClearAllUserPrefs() is the correct place to look for when user preferences get reset, is the importing of bookmarks a "default" option? 

I'll try and debug through the scenario and see. That could be the reason why the imported bookmarks are being scrubbed.  I don't know enough about the underlying system to be sure.  Just going off of first instinct.

Any thoughts?  

Comment 4

[Mike Connor [:mconnor]]

So... this is bad...

dietrich/mano, which of you wants to take this?

Comment 5

[Dietrich Ayala (:dietrich)]

Attachment: fix v1

not sure why the pref is defaulting to true, since if the db is created it gets set to true anyway.

tested scenarios:
- new profile
- migrate from branch
- migrate from older beta

Comment 6

[Asaf Romano (gone)]

Comment on attachment 305806 [details] [diff] [review]
fix v1

reviewed over #places

Comment 7

[Dietrich Ayala (:dietrich)]

Attachment: fix v2

per irc

Comment 8

[Asaf Romano (gone)]

Comment on attachment 305897 [details] [diff] [review]
fix v2

I cannot read without some flags ;)

Comment 9

[Dietrich Ayala (:dietrich)]

Attachment: with context

Comment 10

[Asaf Romano (gone)]

Comment on attachment 306334 [details] [diff] [review]
with context

nit #1: no else after return
nit #2: use either
/**
 *
 */

or // comments style.

r=mano otherwise.

Comment 11

[Dietrich Ayala (:dietrich)]

Checking in browser/app/profile/firefox.js;
/cvsroot/mozilla/browser/app/profile/firefox.js,v  <--  firefox.js
new revision: 1.296; previous revision: 1.295
done
Checking in browser/components/nsBrowserGlue.js;
/cvsroot/mozilla/browser/components/nsBrowserGlue.js,v  <--  nsBrowserGlue.js
new revision: 1.63; previous revision: 1.62
done

Comment 12

[Dietrich Ayala (:dietrich)]

Attachment: as checked in

Comment 13

[Dietrich Ayala (:dietrich)]

backed out for 20ms Ts regression

Checking in browser/app/profile/firefox.js;
/cvsroot/mozilla/browser/app/profile/firefox.js,v  <--  firefox.js
new revision: 1.303; previous revision: 1.302
done
Checking in browser/components/nsBrowserGlue.js;
/cvsroot/mozilla/browser/components/nsBrowserGlue.js,v  <--  nsBrowserGlue.js
new revision: 1.70; previous revision: 1.69
done

Comment 14

[Dietrich Ayala (:dietrich)]

Ts went back down after backout.

Comment 16

[Emil Ivanov]

This bug was created after i wanted to test bug 389449 if its still reproducible, because it was in unconfirmed state for a long time. So adding it in block list to be easier for me to track and check it later again if its reproducible.
Now with all bookmarks restored(erased) to defaults i cant really determine. When the current bug is fixed i will check again the other one.

Comment 17

[Dietrich Ayala (:dietrich)]

relanding post-json, will watch Ts.

Checking in browser/components/nsBrowserGlue.js;
/cvsroot/mozilla/browser/components/nsBrowserGlue.js,v  <--  nsBrowserGlue.js
new revision: 1.83; previous revision: 1.82
done
Checking in browser/app/profile/firefox.js;
/cvsroot/mozilla/browser/app/profile/firefox.js,v  <--  firefox.js
new revision: 1.320; previous revision: 1.319
done

Comment 18

[Dietrich Ayala (:dietrich)]

Attachment: as checked in

unrotted, as checked in

Comment 19

[Dietrich Ayala (:dietrich)]

on qm-plinux-fast01, went from 1346 to 1350. however, that's well within the noise level, as the runs previous were anywhere from 1342 to 1359.

Comment 20

[Marco Bonardo [:mak]]

there's a problem in check-in
i've filled Bug 425640

Comment 21

[Emil Ivanov]

is bug 425457 caused by

> 409 +      * - browser.places.createdSmartBookmarks

Comment 22

[Tracy Walker [:tracy]]

Verified with Windows build from 2008042305

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