510583 - Firefox update fails to include all bookmarks from previous edition.

Status: VERIFIED FIXED

(Firefox :: Bookmarks & History, defect)

Description

[oldmuddy]

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]]

Updated from which Version ?

Comment 2

[Tyler Downer [He/Him]]

http://support.mozilla.com/en-US/kb/Lost+Bookmarks?s=lost+bookmarks may help.

Comment 3

[Marco Bonardo [:mak]]

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 7

[[:Cww]]

Seems to happen updating from 3.0.13 to 3.5.2 via the pushed MU offer.

Comment 8

[[:Cww]]

(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]]

(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]]

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]]

Attachment: 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]]

Can this block the next prompted MU?

Comment 13

[Mike Beltzner [:beltzner, not reading bugmail]]

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]]

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]]

> 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]]

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)]

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]]

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]]

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 - ex-MoCo]]

Can we get clear reproduction steps to cause this issue, please?

Comment 21

[Dietrich Ayala (:dietrich)]

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]]

(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)]

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 25

[Dietrich Ayala (:dietrich)]

checked in on head and relbranch.

Comment 26

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Do we have any tests in this area? Shall we add a Litmus / Mozmill test?

Comment 27

[[:Cww]]

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][⌚️UTC+2]]

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)]

RESOLVED FIXED since this was a 1.9.0-only issue.

Comment 30

[hnorthrup]

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)]

[e-mail]: 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]]

verified with 3.0.14 build2 on Mac 10.4 and Win XP

Comment 35

[Al Billings [:abillings - ex-MoCo]]

Was this only checked into the release tree for 1.9.0.14?

Comment 36

[Marco Bonardo [:mak]]

yes, it's the only affected version.