Closed Bug 701457 Opened 13 years ago Closed 11 years ago

Firefox 8 destroys bookmarks with Mac AFP network home account.

Categories

(Firefox :: Bookmarks & History, defect)

8 Branch
x86
macOS
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 719952

People

(Reporter: info, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Build ID: 20110928134238

Steps to reproduce:

1. Install Firefox 8 on a 10.6.8, fully patched Mac, bound to a Mac 10.6.8 server.
2. Login to a network account, with an network home via AFP on that Mac.
3. Open Firefox 8.
4. Click Bookmarks > Show All Bookmarks
5. Click the "star" menu, choose Restore...
6. Restore a known good bookmarks*.json bookmarks file.


Actual results:

1. Bookmarks are correctly restored. Toolbar and Bookmarks menus correctly display bookmarks.
2. Quit Firefox.
3. Open Firefox.
4. Observe that all bookmarks are gone, all Bookmark Toolbar bookmarks are gone.
5. Click Bookmarks > Show All Bookmarks.
6. Observe that under "All Bookmarks," there are now three empty folders entitled "(no title)".
7. Observe that all bookmarks are gone.
8. Observe that subsequent efforts to restore bookmarks will throw the error "Unable to process the backup file."

I have reproduced this on two separate networks, multiple workstations, different servers.


Expected results:

1. Bookmarks should be retained.
2. Bookmarks should be able to be reimported.
Severity: normal → critical
Removing the profile temporarily allows import.  But bookmarks are gone when the browser is restarted.
Same results if importing bookmarks from an .html backup.
Sweet.  Just duplicated this in 7.0.1.  This likely goes back quite a while.
Blocks: 719952
Status: UNCONFIRMED → NEW
Ever confirmed: true
The 3.6 series does not have this bug. It started in 4.0.
Very preliminary testing suggests that Firefox 10.0, released today, may have addressed this bug.  We've run a very small sample (one, in fact) and bookmarks now appears to be preserved and can be reliably edited.

Additionally, it would appears that https://bugzilla.mozilla.org/show_bug.cgi?id=700397 has been addressed.

Would love some corroboration on this. We'll continue to test and update as our sample size increases.
I couldn't repeat my problem with bookmarks disappearing between sessions
with remote home directories.  So 702285 seems to resolved.
Now to figure out in-browser PDFs. Whee!
I confirm that bookmarks no longer disappear. However, the behavior I reported in 717406 still occurs. After the Awesome Bar stops working, no new bookmarks more are retained when Firefox is closed and reopened.

Is 717406 a different bug, or is it another symptom of a deeper issue with the way Firefox uses sqlite on OS X with remote home directories?
Agreed. I've just reproduced 717406 using AFP homes on Intel 10.5.8 with FF 10.0. Less of a "show stopper" for us than the other two. I'll cross-post this comment there.

I believe that all of these are related to the way FF uses sqlite and how that, in turn, affects network homes.
I believe that this bug remains fixed in FF 11.0 on Mac OS 10.5.8 / 10.6.8 in a networked homes environment.

Can anyone else corroborate?
I seem to be having the same issue with Firefox and network homes. Newly added bookmarks are not preserved.

Servers are running Mac OSX 10.6.7 and clients are running 10.6.8.  I do not have this issue with Portable Home Directories or Local accounts, only the Network Home folders.  Home folders are shared via AFP. Behavior has been the same with FF 10.0.1, 12.0.0 and 13.0.0.

What I have observed is that bookmarks are added to the toolbar and remain during that session.  If I quit and reopen Firefox, the bookmarks in the toolbar revert to the previous state.  While watching the places.sqlite file, the modification date does not seem to update when FF is quit. It is almost as if the new data never gets written to that file.

I performed a bookmarks backup, and saved the .json file to the desktop. Occasionally, this seemed to trigger the backups in the usual location to update as well, and occasionally the places.sqlite file would also update.

I have tested this with a single account on multiple systems and the behavior is consistent.  I also rebuilt one account from scratch and witnessed the same behavior.
there's nothing we can do here, see https://bugzilla.mozilla.org/show_bug.cgi?id=719952#c4 for a workaround
No longer blocks: tb-enterprise, 719952
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.