259238 - firefox overwrites bookmarks.html file after I change the browser.bookmarks.file config parameter

Status: RESOLVED WONTFIX

(Firefox :: Bookmarks & History, defect)

Description

[Meni Taub]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040911 Firefox/0.10
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040911 Firefox/0.10

Just installed firefox PR 1.0, wanted to get use my bookmarks file which is
stored in a different directory. Created the configuration key:
browser.bookmarks.file and specified my file (e.g.
/home/mtaub/myfiles/bookmarks.html) and firefox OVERWROTE THAT FILE!. This is
bad anyway becuase someone might want to sycronize firefox and mozilla bookmarks.

Reproducible: Always
Steps to Reproduce:
1. install latest firefox
2. create a key 'browser.bookmarks.file' 
3. enter a name of existing bookmark file

Actual Results:  
that file is overwritten

Expected Results:  
That file shuld never, i repeat, never be overwritten.

Comment 1

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Now that mconnor pointed out some things to me.. the bookmarks file is
write-only during a session, and is only read at browser launch.  Changing this
(hidden) pref during a session will only cause bookmarks to be written there; so
it's normal that what was there was overwritten the next time bookmarks were
saved.  If you'd like to have this behaviour, you can edit user.js before you
launch the browser.  Note also that if you have mozilla and firefox pointing to
the same bookmarks file, and you use them both at the same time, any bookmarks
changes in one will get overwritten by the other.

-> WONTFIX, sorry

Comment 2

[[e-mail]]

If you still want to share the file, then you'll find that using the File ->
Open Bookmarks File menuitem in Mozilla's bookmarks manager is the easiest way.

Comment 3

[Ramona]

I found that by renaming the bookmarks.html file in Firefox 1.0PR to
Xbookmarks.html prior to adding the script (browser.bookmarks.file -
C:\Bookmarks\bookmarks.html) to about:config, there is no risk of the shared
bookmarks.html file being overwritten.

Comment 4

[Mike Connor [:mconnor]]

*** Bug 282490 has been marked as a duplicate of this bug. ***

Comment 5

[Mike Connor [:mconnor]]

*** Bug 282490 has been marked as a duplicate of this bug. ***

Comment 6

[Jesse Ruderman]

*** Bug 285634 has been marked as a duplicate of this bug. ***

Comment 7

[bugzilla]

(In reply to comment #1)
> Now that mconnor pointed out some things to me.. the bookmarks file is
> write-only during a session, and is only read at browser launch.  Changing this
> (hidden) pref during a session will only cause bookmarks to be written there; so
> it's normal that what was there was overwritten the next time bookmarks were
> saved.  If you'd like to have this behaviour, you can edit user.js before you
> launch the browser.  Note also that if you have mozilla and firefox pointing to
> the same bookmarks file, and you use them both at the same time, any bookmarks
> changes in one will get overwritten by the other.
> 
> -> WONTFIX, sorry

Today I lost my bookmarks even though I had not changed anything
bookmark-related.  The exact sequence of events was something like this:

* Opened Firefox
* Realized I had not plugged in the flash drive where my bookmarks reside
* Plugged it in
* Closed Firefox (to relaunch it to pick up my bookmarks)
* Firefox overwrote my bookmarks with an empty bookmark file

Granted that the designed behavior makes this difficult to change, the designed
behavior (blindly overwriting files regardless of their existence) is broken and
should be changed.  User data should *never ever* be overwritten without at
least an "are you sure?"  A possible fix might be something like this:

* On browser start, read bookmarks.
* Reopen bookmark file write-only.
* If the browser.bookmarks.file pref changes, close the existing file cleanly,
then repeat the startup sequence (read, reopen write-only) with the new file.
* Optionally, ask whether the user wants to import bookmarks from the old file
to the new file.

This lets the bookmark file still be read-only during a session but avoids nasty
bugs like loss of user data built up over months or years.

Comment 8

[Mike Connor [:mconnor]]

Well, this goes away once we move to unified storage, at which point the pref
dies since we won't have a separate bookmarks file anymore.  

In the meantime, the only solution that fixes that particular bug, short of
disabling the bookmarks service completely if there's no bookmarks loaded from a
file at startup, is disabling the pref so that the bookmarks file is linked to
the profile, so if the profile isn't available, we don't start up.

Maybe as a stopgap, have a second pref
browser.bookmarks.enable_potential_dataloss_by_specifying_a_distinct_bookmarks_file
and require that be set to true to support this..... perhaps THAT will clue
people in that this buried pref isn't safe to use in some cases.

Comment 9

[bugzilla]

(In reply to comment #8)
> Well, this goes away once we move to unified storage, at which point the pref
> dies since we won't have a separate bookmarks file anymore.  

From this, I gather that I ought to migrate my entire profile to my flash drive
instead of just the bookmark file.

> In the meantime, the only solution that fixes that particular bug, short of
> disabling the bookmarks service completely if there's no bookmarks loaded from a
> file at startup, is disabling the pref so that the bookmarks file is linked to
> the profile, so if the profile isn't available, we don't start up.

I think either of those would be fine, really -- it sounds like either solution
would stop Firefox from causing loss of user data.  In fact the first would be
"better" in that if there's no bookmark file available, that shouldn't stop the
browser from starting up.  But I can see why it's not really desirable to do
that amount of coding when the whole model is about to change and make it
unnecessary anyway.

> Maybe as a stopgap, have a second pref
>
browser.bookmarks.enable_potential_dataloss_by_specifying_a_distinct_bookmarks_file
> and require that be set to true to support this..... perhaps THAT will clue
> people in that this buried pref isn't safe to use in some cases.

The trouble with thinking like that is, there are a lot of "buried prefs" that
provide desirable and in some cases critical functionality, like turning the
shell: protocol handler on and off, controlling how many concurrent requests are
allowed at once, and controlling how much RAM cache Firefox gets.  There's no
sense that buried prefs are dangerous after you start seeing stuff like that.

The Linux kernel does a good thing by labeling certain options NEW or
EXPERIMENTAL; perhaps there could be an experimental.* hierarchy for prefs
considered "unsupported and potentially dangerous".  People will have a
different reaction to experimental.browser.bookmarks.file than they will to the
current name.

Netscape 4.x and previous versions let you specify the location of individual
files like bookmarks, so people expect that Firefox would let you do that too. 
I was surprised not to find it in the Advanced settings, actually.  So of course
when people find the browser.bookmarks.file pref, they use it, because it
provides the functionality they're looking for.

There are perfectly valid reasons for carrying your bookmarks around separate
from the rest of your profile -- for one, your whole profile may not fit on a
flash drive.  For another, bookmarks are an inherently dynamic whereas the rest
of the profile is pretty static for the vast majority of people.  Why take up
the room on the flash drive (or CD-RW, or Zip disk or whatever) with data that
doesn't change and may crowd out data you need?

Most of which is neither here nor there, except my main points which are: 1)
there are reasons for users to want to do exactly what browser.bookmarks.file
lets them do; 2) blaming the user because a seemingly simple option behaves in a
non-obvious way is bad form (and gives Microsoft another thing to beat
open-source development over the head with).

Comment 10

[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