all bookmarks lost when using "browser.bookmarks.file" pref and switching profile

VERIFIED FIXED in mozilla1.4alpha

Status

Core Graveyard
Profile: BackEnd
--
critical
VERIFIED FIXED
15 years ago
2 years ago

People

(Reporter: Eric Belhaire, Assigned: Conrad Carlen (not reading bugmail))

Tracking

({dataloss})

Trunk
mozilla1.4alpha
x86
Windows 98
dataloss
Bug Flags:
blocking1.3 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed1.3.1)

Attachments

(1 attachment)

1.18 KB, patch
Conrad Carlen (not reading bugmail)
: review+
Alec Flett
: superreview+
Details | Diff | Splinter Review
(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3) Gecko/20030308
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3) Gecko/20030308

I have two profiles :
profile A : 
includes the definition of a user_pref("browser.bookmarks.file",
"C:\\WINDOWS\\Application Data\\Mozilla\\Profiles\\bookmarks.html");
to use a bookmark file located outside the profile directory.

profile B : 
is a normal profile (with the default bookmark created during its creation.
When I switched from profile B to profile A, the bookmark file of A has been
replaced by the one of B.

All my bookmarks of A has been lost.

Reproducible: Always

Steps to Reproduce:
1. create 2 profiles A and B
2. add the definition of user_pref("browser.bookmarks.file",
"C:\\WINDOWS\\Application Data\\Mozilla\\Profiles\\bookmarks.html"); to use a
bookmark file outside the profile directory in the profile A
3. quit Mozilla
4. launch Mozilla with profile B
5. switch to profile A with the command Tools>Switch Profile

Actual Results:  
The bookmark of profile A are overwritten with those of profile B

Expected Results:  
Load the bookmarks of A (instead of overwrite them)
(Reporter)

Updated

15 years ago
Flags: blocking1.3?

Updated

15 years ago
Keywords: dataloss
Bookmarks bug; the bookmarks should be saved on profile shutdown.
Assignee: jaggernaut → ben
Component: Profile Manager FrontEnd → Bookmarks
QA Contact: gbush → kasumi

Comment 2

15 years ago
this is really bad - used the steps above to reproduce- and ended up with no
bookmarks in either profile

This did not occur when I closed app and restarted with different profile- only
when using tools/switching profiles.

reassigning- please reassign if I have done so in error
Status: UNCONFIRMED → NEW
Component: Bookmarks → Profile Manager BackEnd
Ever confirmed: true
QA Contact: kasumi → gbush
(Assignee)

Comment 3

15 years ago
> Bookmarks bug; the bookmarks should be saved on profile shutdown.

It does. See nsBookmarksService::Observe. The problem here is that the file is
located by means of the "browser.bookmarks.file" rather than the normal case of
being in the profile folder.

Grace, just because the bug happens with profile switching doesn't mean it's a
profile mgr bug. Lots of components have profile change observing code. If the
bug is in that code, it's not a profile mgr bug. But, I'll take it though.
Status: NEW → ASSIGNED

Comment 4

15 years ago
I also lost bookmarks in  the second profile, that were stored in default
location  ie in profile directory.   
(Assignee)

Comment 5

15 years ago
That's because the switch between pref and not-pref specified file didn't
happen. If neither profile has its bookmarks specified by that pref, does this
happen?
Assignee: ben → ccarlen
Status: ASSIGNED → NEW

Comment 6

15 years ago
no, if profiles are using default bookmark file location- the switch works as
expected
(Assignee)

Comment 7

15 years ago
Thanks for the clarification.

I see the problem. nsBookmarksService is observing "profile-do-change" to load
the new bookmarks. It should be observing "profile-after-change" because, on
that phase, the new prefs will already have been read.

BTW, is the only way to set this pref to add it to your prefs file by hand?
Status: NEW → ASSIGNED
Summary: all bookmarks lost when changing with "Tools" > "Switch Profile" → all bookmarks lost when using "browser.bookmarks.file" pref and switching profile
Target Milestone: --- → mozilla1.4alpha

Comment 8

15 years ago
that's the only way I know how to do it,  Eric?
(Reporter)

Comment 9

15 years ago
Yes, doing it by hand is the only way I know (and it's how 
I did it).

Updated

15 years ago
Flags: blocking1.3? → blocking1.3-

Comment 10

15 years ago
Created attachment 117080 [details] [diff] [review]
per conrad

Updated

15 years ago
Attachment #117080 - Flags: superreview?(alecf)
Attachment #117080 - Flags: review?(ccarlen)
(Assignee)

Comment 11

15 years ago
Comment on attachment 117080 [details] [diff] [review]
per conrad

Ah - thanks so much for doing this :-)
Attachment #117080 - Flags: review?(ccarlen) → review+

Comment 12

15 years ago
Comment on attachment 117080 [details] [diff] [review]
per conrad

sr=alecf
Attachment #117080 - Flags: superreview?(alecf) → superreview+

Comment 13

15 years ago
checked in
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Updated

15 years ago
Whiteboard: 1.3.1

Comment 14

15 years ago
verified build 2003032104
Status: RESOLVED → VERIFIED
(Assignee)

Comment 15

15 years ago
Checked into 1.3 branch after email from Asa.

Updated

15 years ago
Whiteboard: 1.3.1 → fixed1.3.1

Updated

15 years ago
Blocks: 203343
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.