219772 - Actively update bookmarks file so it can be shared by multiple profiles

Status: RESOLVED WONTFIX

(Firefox :: Bookmarks & History, enhancement)

Description

[shane]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030918 Mozilla Firebird/0.6.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030918 Mozilla Firebird/0.6.1

if you use multiple profiles but use 1 bookmark file,
ex  ~/.phoenix/default/xxxxxxx.slt  uses bookmark file ~/.phoenix/bookmark.html
    ~/.phoenix/default2/xxxxxxx.slt  uses bookmark file ~/.phoenix/bookmark.html

by setting in prefs.js in both profiles prefs.js files:
user_prefs("browser.bookmarks.file", "~/.phoenix/bookmark.html");

then you create a bookmark in profile default2 and close default2 firebird, then
close default firebird the bookmarks you created in default2 are lost.  But if
you create bookmarks in default2 firebird then close default firebird then close
default2 firebird it works the way expected...but if you create booksmarks in
both profiles you are kinda screwed...

i would assume the cause is the browser isnt saving the bookmarks until exiting
but this kinda causes a problem because it will overwrite the other profiles
changes...tabs are great but sometimes a new browser is nice too.

Reproducible: Always

Steps to Reproduce:
1.configure 2 profiles of firebird to use same bookmark file
2.create bookmarks in both profiles ... and exit all firebirds
3.you lose which ever firebird exits first bookmarks

Actual Results:  
which ever profile i close first looses the new bookmarks i created

Expected Results:  
save both profiles' bookmarks

its pretty simple ... you are having the browser save upon exiting but by doing
this you will over right the changes made by the first profile that exits.  you
should save to the bookmark.html file when a bookmark is added not when exiting. 

even cooler would be if the bookmarks access button would actively check the
bookmarks file for changes, but this might cause a slow down and having to exit
to reload the bookmarks isnt a big deal.  of course i also check my mail every
5min and that doesnt seem to cause a slow down.

Comment 1

[Mike Connor [:mconnor]]

Bookmarks aren't intended to be shared "live" as it were.  Why are you using
multiple profiles anyway?  If you just want a new browser window, using a proper
remote script or Ctrl-N will work better.

Considering that multiple profiles weren't even supposed to be accessible
without a command line, this is pretty far off the radar

updating summary and severity, expecting WONTFIX, but leaving it to sit for a
bit first

Comment 2

[Pham]

0

Comment 3

[Mike Connor [:mconnor]]

-> reopen

Comment 4

[Daniel Bonniot]

I experienced a related problem. I wanted to share my bookmarks file with
mozilla. So while firebird (0.7) was running, i went into about:config, added
the property browser.bookmarks.file to the shared file. Exit, restart. Still the
same bookmarks (firebird default). After some research, I found that firebird
was indeed using the new location. It's "just" that when exiting, it saved its
bookmarks to the new location, overwriting my previous file (I had a backup,
thanks for asking).

I report this as a comment here, because the problem is the same, although my
usage pattern is different (and probably much more common). Firebird should not
blindly write to the bookmarks file, but at least detect if it has been modified
since the last time it read it and ask the user what to do. The best would be to
monitor its changes at regular intervals, reload automatically if it has
changed, and save as soon as bookmarks have been edited (locking the bookmarks
file during the save).

BTW, this is a dataloss bug in a fairly common situation, so I think the
severity should be much higher.

Comment 5

[Samir L. Boulema]

Upped the severity to major per comment #4 and added keyword.

Comment 6

[Mike Connor [:mconnor]]

its dataloss if you do something with the pref that its not intended for. 
Sharing of profile data is not supported, if you try to do it then you will have
problems.

the design currently is intended to deal with a single instance, so there's no
need for the checking you're talking about here.  If this gets implemented and
supported, then you will have a different situation, until then its an enhancement.

Comment 7

[Daniel Bonniot]

Sharing the bookmarks is explicitely advertised in the tips and tricks page,
which is linked to from the FAQ:
http://texturizer.net/firefox/faq.html#netscape
"
If you are using Netscape 6/7 or Mozilla, you can _share_ your bookmarks with
Firefox.
"

If you follow those instructions, but happen to decide to use about:config
instead of editing user.js by hand (which should be promoted, shouldn't it?),
you get a major data loss (see my story). And running multiple instances is not
even involved in that case. Other people _will_ lose their bookmarks with the
current behaviour, especially since about:config and now Preferential are
getting better known. I don't think this will give them a first good impression
of firefox, nor that they will agree that this issue is actually an enhancement
request.

Now, I perfectly understand that implementing the dynamic reloading and locking
is non trivial. But detecting that the bookmarks have changed, and for instance
saving a backup before overwriting, would already solve the main part, which is
data loss.

Comment 8

[Michael Gall]

Bbug 218636 is to add a bookmark backup file, this would solve the suggested
stopgap here. It has been confirmed so sit tight.

Comment 9

[shane]

If you make a backup of the original bookmarks.html file could you also add
something like this to the program ... would require diff and grep if there is
nothing in (* i guess C *) that can do it.  Would be easy to create a script
that started mozilla and then ran this, but while your up i figured i would ask ;)


diff bookmarks.html bookmarks-backup.html -D
@#SOMETHINGthatWOULDneverBEinAbookmark#@.@#@ | grep -v
"@#SOMETHINGthatWOULDneverBEinAbookmark#@.@#@" > output.html
rm bookmarks.html bookmarks-backup.html
mv output.html bookmarks.html

Comment 10

[ljbmailprotect-mozilla]

(In reply to comment #4)
> I experienced a related problem. I wanted to share my bookmarks file with
> mozilla. So while firebird (0.7) was running, i went into about:config, added
> the property browser.bookmarks.file to the shared file. Exit, restart. Still the
> same bookmarks (firebird default). After some research, I found that firebird
> was indeed using the new location. It's "just" that when exiting, it saved its
> bookmarks to the new location, overwriting my previous file (I had a backup,
> thanks for asking).
> 
> I report this as a comment here, because the problem is the same, although my
> usage pattern is different (and probably much more common). Firebird should not
> blindly write to the bookmarks file, but at least detect if it has been modified
> since the last time it read it and ask the user what to do. The best would be to
> monitor its changes at regular intervals, reload automatically if it has
> changed, and save as soon as bookmarks have been edited (locking the bookmarks
> file during the save).
> 
> BTW, this is a dataloss bug in a fairly common situation, so I think the
> severity should be much higher.


I reported the same behavior as bug 282490 when sharing the bookmarks file
between two firefox installations on a dual boot system.  It also resulted in
complete dataloss of the bookmarks file.

Comment 11

[Mike Connor [:mconnor]]

(In reply to comment #10)

> I reported the same behavior as bug 282490 when sharing the bookmarks file
> between two firefox installations on a dual boot system.  It also resulted in
> complete dataloss of the bookmarks file.
> 

You assumed that an undocumented pref worked a certain way, which it doesn't. 
Sometimes I think we should add a disclaimer to about:config saying "If you
don't know what it does, don't touch it."

Comment 12

[Mike Connor [:mconnor]]

Never did this for 1.5, Fx2 will have a sqlite db and that's even more problematic.

Comment 13

[Mike Connor [:mconnor]]

sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change