Closed Bug 260591 Opened 16 years ago Closed 16 years ago
.html not created if it does not exist in profile, bookmarks fail
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10 When a valid bookmarks.html does not exist in a given profile, Firefox does not create one. Attempting to Bookmark a page will bring up the dialog, clicking OK will add it to the Bookmarks menu, but not close the dialog and not write it to a file. Import works the same way. Exitting and restarting the browser will then yield no bookmarks. Reproducible: Always Steps to Reproduce: 1. Move bookmarks.html out of a given profile. 2. Start Firefox and attempt to bookmark a page (note that the dialog will not go away when clicking OK, but will add a bookmark to the menu) 3. Exit and restart Firefox, no bookmarks again. Actual Results: Default bookmarks.html is not created and no bookmarks are saved. Expected Results: Default bookmarks.html created if it doesn't exist within a profile on browser start. This behavior changed between 0.9.3 and 1.0PR. We noticed it as a part of using firefox with a portable profeil (the -Profile switch). Normally, Firefox successfully creates a profile in an empty directory. With 1.0PR, bookmarks now fail.
-> NEW For an in-production profile, you need to get rid of bookmarks.bak as well. So the steps go like this: 1. Remove (or rename) bookmarks.html and bookmarks.bak (if they exist) from your profile. 2. Start Firefox and bookmark a page. 3. Note that the OK button doesn't close the window. You have to hit cancel. 4. Look in the bookmarks menu item and note that about:blank was bookmarked, not the page you wanted. 5. Close Firefox. 6. Note that there is still no bookmarks.html and bookmarks.bak in your profile. 7. Restart Firefox and note that your bookmark (about:blank) is not there any more.
Oops, forget step 4. That's my bad.
why can't I confirm this bug?
Same behavior using FF 1.0 PR on Linux -> OS = All! In the same way, please mark it as NEW! Reporter, you should mark your bug as severity = blocker! This bug may be a dupe of bug 260163!
As a confirmation, this would show up as bookmarks being lost after adding to them or importing them as no bookmarks.html would be saved. As post 4 notes, this bug may be a dupe of bug 260163, though that bug isn't written as generically. Anyone know proper procedure? Resolve this as a duplicate and then add all info to the other bug? Changing OS to All as confirmed on Linux and Windows (and possibly Mac via above-mentioned bug). As to marking as blocker, only higher-ups should do that. Not lowly folks like me :-)
To be more precise: Critical = "crashes, loss of data, severe memory leak" This is exactly what we have here! You can confidently move the severity to critical (more appropriate than blocker, sorry!)! ;-)
confirming with 2004092110-0.10 (aviary1.0) on linux fedora core 2. I followed the steps in comment 1, and my results were slightly different but I think similar enough to be the same issue. * at step 3, I click the Add button, but the dialog doesn't go away. I clicked the button several times (just to check), and each time I got the following js errors: Error: uncaught exception: [Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIRDFRemoteDataSource.Flush]" nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)" location: "JS frame :: chrome://browser/content/bookmarks/addBookmark2.js :: onOK :: line 163" data: no] Error: uncaught exception: [Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIRDFRemoteDataSource.Flush]" nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)" location: "JS frame :: chrome://browser/content/bookmarks/bookmarks.js :: anonymous :: line 1518" data: no] * fwiw, the page I tested bookmarking was this one. but instead of seeing about:blank listed in the Bookmarks menu, the <title> properly appeared. in fact, since I had hit Add several times, I got an instance for each click. (not too surprising. ;) anyhow, as Mike mentioned, I clicked Cancel to actually get rid of the dialog. * after quitting Firefox, no bookmarks.html (or bookmarks.bak) was created in my profile directory. * after restarting Firefox, the added bookmark did not appear in the Bookmarks menu.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Asa wondered whether the fix for bug 218636 might have influenced this issue, but I don't think so. true, this bug is in the PR release (from 9/14), but it also occurs with aviary1.0 builds from 8/9 and 8/5 (before bug 218636 was implemented).
16 years ago
Status: NEW → ASSIGNED
Flags: blocking-aviary1.0? → blocking-aviary1.0+
CREATE wasn't in here; the reason this is cropping up is probably related to us not copying bookmarks.html for profiles created in a non-default dir. Still tracking that down.
16 years ago
Comment on attachment 161090 [details] [diff] [review] 260591-bookmarks-not-created-if-file-doesnt-exist-0.patch firstname.lastname@example.org
in on aviary
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change
QA Contact: mconnor → bookmarks
You need to log in before you can comment on or make changes to this bug.