Last Comment Bug 510583 - Firefox update fails to include all bookmarks from previous edition.
: Firefox update fails to include all bookmarks from previous edition.
Status: VERIFIED FIXED
[has patch][has review]
: dataloss, fixed1.9.0.15, verified1.9.0.14
Product: Firefox
Classification: Client Software
Component: Bookmarks & History (show other bugs)
: 3.0 Branch
: Other Windows XP
: -- major (vote)
: ---
Assigned To: Marco Bonardo [::mak]
:
: Marco Bonardo [::mak]
Mentors:
: 510853 512140 512234 513362 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-08-14 14:06 PDT by oldmuddy
Modified: 2009-10-29 10:43 PDT (History)
18 users (show)
samuel.sidler+old: blocking1.9.0.14+
samuel.sidler+old: blocking1.9.0.15+
hskupin: in‑testsuite?
hskupin: in‑litmus?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
unaffected
-
unaffected


Attachments
patch v1.0 (2.84 KB, patch)
2009-08-25 15:05 PDT, Marco Bonardo [::mak]
dietrich: review+
samuel.sidler+old: approval1.9.0.14+
samuel.sidler+old: approval1.9.0.15+
Details | Diff | Splinter Review

Description oldmuddy 2009-08-14 14:06:15 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

Today my Firefox updated, but only part (between 1/3 and 1/2) of the bookmarks show up in the new version.

Reproducible: Always
Comment 1 Matthias Versen [:Matti] 2009-08-14 15:52:24 PDT
Updated from which Version ?
Comment 2 Tyler Downer [:Tyler] 2009-08-15 13:15:56 PDT
http://support.mozilla.com/en-US/kb/Lost+Bookmarks?s=lost+bookmarks may help.
Comment 3 Marco Bonardo [::mak] 2009-08-17 01:03:16 PDT
could be what has been imported is bookmarks.html (an old version of your bookmarks).

you could try to restore bookmarks from a JSON backup (Restore functionality is in the Library reachable through Organize Bookmarks)
Comment 4 Marco Bonardo [::mak] 2009-08-17 01:59:06 PDT
*** Bug 510853 has been marked as a duplicate of this bug. ***
Comment 5 Marco Bonardo [::mak] 2009-08-17 01:59:15 PDT
*** Bug 510681 has been marked as a duplicate of this bug. ***
Comment 6 Marco Bonardo [::mak] 2009-08-17 02:00:55 PDT
*** Bug 510853 has been marked as a duplicate of this bug. ***
Comment 7 [:Cww] 2009-08-19 17:54:16 PDT
Seems to happen updating from 3.0.13 to 3.5.2 via the pushed MU offer.
Comment 8 [:Cww] 2009-08-19 17:58:23 PDT
(sorry, I'm not saying that's the ONLY time it happens but it also happens in that instance.)

Also, we've found that the JSON files /are/ complete and a very good workaround.
Comment 9 [:Cww] 2009-08-24 09:46:40 PDT
(In reply to comment #3)
http://support.mozilla.com/tiki-view_forum_thread.php?locale=en-US&comments_parentId=421673&forumId=1 suggests that the bookmarks.html import is the right hypothesis.
Comment 10 Marco Bonardo [::mak] 2009-08-25 09:44:59 PDT
Yes, 3.0 is not correctly flipping the pref to false once used, and on upgrade that causes 3.5 to import bookmarks.html because the pref says to do so. we could investigate a fix for 3.0.14/15, i just fear about possible regressions since that pref is used differently on 1.9.0 branch.
Comment 11 Marco Bonardo [::mak] 2009-08-25 15:05:05 PDT
Created attachment 396559 [details] [diff] [review]
patch v1.0

We could take this on 3.0.x to try blocking the issue for users moving to 3.5, would be a 3.0 only patch.  What about this?
Comment 12 [:Cww] 2009-08-25 16:45:13 PDT
Can this block the next prompted MU?
Comment 13 Mike Beltzner [:beltzner, not reading bugmail] 2009-08-25 16:47:04 PDT
This seems like a pretty serious issue; is it 100% reproducible? Do we know what cases cause the Firefox 3.0 bookmarks.html import to not flip the appropriate preference / how common this issue is?
Comment 14 Marco Bonardo [::mak] 2009-08-25 16:54:17 PDT
The code in browserGlue has various branches, not all of them flip back the pref. if a certain combination of prefs exists we hit this.
Comment 15 Daniel Veditz [:dveditz] 2009-08-25 21:54:57 PDT
> since that pref is used differently on 1.9.0 branch.

Always a dangerous thing!

> if a certain combination of prefs exists we hit this.

What combination? How common is that combination? Is it something that depends on a user explicitly changing a setting somewhere, or are they settings we automatically change to store some kind of state?
Comment 16 Daniel Veditz [:dveditz] 2009-08-25 21:57:20 PDT
I noticed that status1.9.1 is set to "unaffected" but there's no explanation in the bug. A firefox 3.5 user can't get into the same combination as a 1.9.0 user and hit this problem with an eventual upgrade to 3.next?
Comment 17 Samuel Sidler (old account; do not CC) 2009-08-25 22:23:11 PDT
Dan: I set that per Marco. The issue is only present on 1.9.0 because of how it sets that pref. The only place this would need to land is on the 1.9.0 branch.

We really need some more details here, especially if we should consider blocking on this bug and respinning. Dan's comment 15 is a good start...

Also: Is it clear that this scenario is the only or majority one that causes users upgrading from 3.0 to 3.5 to "lose" some of their bookmarks? Are there others?
Comment 18 Marco Bonardo [::mak] 2009-08-26 06:01:24 PDT
We discussed this on IRC, sorry for not coming back with information.

The known affected scenario are users who have hit a places.sqlite corruption in 3.0.x, their db has been restored but the pref has not been flipped off. On upgrade to 3.5 it will read the pref to true and import bookmarks from bookmarks.html.
3.5 is unaffected because the prefs are correctly flipped off once used. We cannot take the patch that is on 3.5 on 3.0 because it also requires backend changes in Places initialization, that is somehow risky. That's why i provided a 3.0 only change that is a partial part of that patch (for reference it is bug 462366) and should be safe.

There is a workaround, known to support, that is to restore a JSON backup.

(In reply to comment #17)
> Also: Is it clear that this scenario is the only or majority one that causes
> users upgrading from 3.0 to 3.5 to "lose" some of their bookmarks? Are there
> others?

Some kind of corruption of the db could cause loss, but that's unpredictable andwe handle them replacing the db. There are not other known causes that can be fixed atm.
Comment 19 Marco Bonardo [::mak] 2009-08-26 06:03:15 PDT
PS: by "pref is used differently" i meant the pref was acting wrongly in 3.0, causing looping bookmarks restores, and we fixed it in 3.5 so that it just does what it says: imports bookmarks.html and gets flipped back.
Comment 20 Al Billings [:abillings] 2009-08-26 11:12:03 PDT
Can we get clear reproduction steps to cause this issue, please?
Comment 21 Dietrich Ayala (:dietrich) 2009-08-26 11:16:01 PDT
Comment on attachment 396559 [details] [diff] [review]
patch v1.0

this code needs a complete rethink.

r=me for this change, though.
Comment 22 Marco Bonardo [::mak] 2009-08-26 12:17:23 PDT
(In reply to comment #20)
> Can we get clear reproduction steps to cause this issue, please?

since causing a db corruption is not so easy, you could just:
- create a new profile
- add a bookmark in the toolbar
- close the browser and ensure you have at least one json backup in bookmarksBackup profile dir
- open browser and set importBookmarksHTML to true (this is one of the things that happen when the db is found corrupt in 3.0)
- restart browser, check that importBookmarksHTML is still true
- check for updates and install 3.5.2
- check bookmarks.html has been imported
- check importBookmarksHTML has been flipped to false

If you need steps that a user could run into, we'll need to provide a corrupt DB.
Comment 23 Samuel Sidler (old account; do not CC) 2009-08-26 16:48:24 PDT
Comment on attachment 396559 [details] [diff] [review]
patch v1.0

We're going to block on this for 1.9.0.14. This needs to land on CVS HEAD and on GECKO190_20090812_RELBRANCH.

Approved for 1.9.0.14 and 1.9.0.15. a=ss for release-drivers
Comment 24 Drew Willcoxon :adw 2009-08-26 17:06:52 PDT
*** Bug 512140 has been marked as a duplicate of this bug. ***
Comment 25 Dietrich Ayala (:dietrich) 2009-08-26 17:28:33 PDT
checked in on head and relbranch.
Comment 26 Henrik Skupin (:whimboo) 2009-08-27 01:25:43 PDT
Do we have any tests in this area? Shall we add a Litmus / Mozmill test?
Comment 27 [:Cww] 2009-08-27 11:26:59 PDT
We may need to have tests that deliberately corrupt files to reproduce stuff like this... are there plans for that kind of thing?
Comment 28 Henrik Skupin (:whimboo) 2009-08-27 12:41:29 PDT
Lets flag for litmus/testsuite so we can make a decision in which way the test has to be implemented.
Comment 29 Samuel Sidler (old account; do not CC) 2009-08-27 15:37:07 PDT
RESOLVED FIXED since this was a 1.9.0-only issue.
Comment 30 hnorthrup 2009-08-27 18:23:05 PDT
I recently reported this bug after it happened to me when I upgraded from 3.x to 3.5.2, so how can it be listed as RESOLVED FIXED as a 1.9.0-only issue? I've been running Firefox since version 0.9 and this bug has never happened before--my bookmarks were always carried forward to the latest version with each upgrade.
Comment 31 Samuel Sidler (old account; do not CC) 2009-08-27 19:05:01 PDT
hnorthrup@yahoo.com: This bug only happens on migration from 3.0.x to 3.5.x. The fix happened on the 3.0.x side (since it was a problem there). This bug has been fixed and we will push the fix in Firefox 3.0.14 so users upgrading from that to 3.5.x will no longer see it.
Comment 32 Tracy Walker [:tracy] 2009-08-28 12:15:39 PDT
verified with 3.0.14 build2 on Mac 10.4 and Win XP
Comment 33 Daniel Veditz [:dveditz] 2009-08-28 15:57:05 PDT
*** Bug 513362 has been marked as a duplicate of this bug. ***
Comment 34 Tracy Walker [:tracy] 2009-09-14 15:39:50 PDT
*** Bug 512234 has been marked as a duplicate of this bug. ***
Comment 35 Al Billings [:abillings] 2009-09-16 17:04:52 PDT
Was this only checked into the release tree for 1.9.0.14?
Comment 36 Marco Bonardo [::mak] 2009-09-16 17:14:44 PDT
yes, it's the only affected version.

Note You need to log in before you can comment on or make changes to this bug.