The default bug view has changed. See this FAQ.

Firefox update fails to include all bookmarks from previous edition.

VERIFIED FIXED

Status

()

Firefox
Bookmarks & History
--
major
VERIFIED FIXED
8 years ago
8 years ago

People

(Reporter: oldmuddy, Assigned: mak)

Tracking

({dataloss, fixed1.9.0.15, verified1.9.0.14})

3.0 Branch
Other
Windows XP
dataloss, fixed1.9.0.15, verified1.9.0.14
Points:
---
Bug Flags:
blocking1.9.0.14 +
blocking1.9.0.15 +
in-testsuite ?
in-litmus ?

Firefox Tracking Flags

(status1.9.2 unaffected, blocking1.9.1 -, status1.9.1 unaffected)

Details

(Whiteboard: [has patch][has review])

Attachments

(1 attachment)

2.84 KB, patch
dietrich
: review+
Samuel Sidler (old account; do not CC)
: approval1.9.0.14+
Samuel Sidler (old account; do not CC)
: approval1.9.0.15+
Details | Diff | Splinter Review
(Reporter)

Description

8 years ago
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
Updated from which Version ?
http://support.mozilla.com/en-US/kb/Lost+Bookmarks?s=lost+bookmarks may help.
(Assignee)

Comment 3

8 years ago
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)
(Assignee)

Updated

8 years ago
Duplicate of this bug: 510853
(Assignee)

Updated

8 years ago
Duplicate of this bug: 510681
(Assignee)

Updated

8 years ago
Duplicate of this bug: 510853

Comment 7

8 years ago
Seems to happen updating from 3.0.13 to 3.5.2 via the pushed MU offer.
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: common-issue+

Comment 8

8 years ago
(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

8 years ago
(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.
(Assignee)

Comment 10

8 years ago
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.
(Assignee)

Comment 11

8 years ago
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?
Attachment #396559 - Flags: review?(dietrich)

Comment 12

8 years ago
Can this block the next prompted MU?
Flags: wanted-firefox3.5?
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?
blocking1.9.1: --- → ?
Flags: blocking-firefox3.6+
Flags: wanted-firefox3.5?
(Assignee)

Comment 14

8 years ago
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.
status1.9.1: --- → unaffected
blocking1.9.1: ? → -
Flags: blocking1.9.0.15?
Flags: blocking1.9.0.14?
Flags: blocking-firefox3.6+
Keywords: dataloss
> 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?
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?
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?
Version: unspecified → 3.0 Branch
(Assignee)

Comment 18

8 years ago
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.
(Assignee)

Comment 19

8 years ago
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.
Can we get clear reproduction steps to cause this issue, please?
Comment on attachment 396559 [details] [diff] [review]
patch v1.0

this code needs a complete rethink.

r=me for this change, though.
Attachment #396559 - Flags: review?(dietrich) → review+
Whiteboard: [has patch][has review]
(Assignee)

Comment 22

8 years ago
(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 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
Attachment #396559 - Flags: approval1.9.0.15+
Attachment #396559 - Flags: approval1.9.0.14+
Flags: blocking1.9.0.15?
Flags: blocking1.9.0.15+
Flags: blocking1.9.0.14?
Flags: blocking1.9.0.14+
Assignee: nobody → mak77
Flags: blocking1.9.0.15?
Flags: blocking1.9.0.15+
Flags: blocking1.9.0.14?
Flags: blocking1.9.0.14+
Flags: blocking1.9.0.15?
Flags: blocking1.9.0.15+
Flags: blocking1.9.0.14?
Flags: blocking1.9.0.14+

Updated

8 years ago
Duplicate of this bug: 512140
checked in on head and relbranch.
Keywords: fixed1.9.0.14, fixed1.9.0.15
Do we have any tests in this area? Shall we add a Litmus / Mozmill test?

Comment 27

8 years ago
We may need to have tests that deliberately corrupt files to reproduce stuff like this... are there plans for that kind of thing?
Lets flag for litmus/testsuite so we can make a decision in which way the test has to be implemented.
Flags: in-testsuite?
Flags: in-litmus?
RESOLVED FIXED since this was a 1.9.0-only issue.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED

Comment 30

8 years ago
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.
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.
verified with 3.0.14 build2 on Mac 10.4 and Win XP
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.0.14 → verified1.9.0.14
Duplicate of this bug: 513362
(Assignee)

Updated

8 years ago
status1.9.2: --- → unaffected

Updated

8 years ago
Duplicate of this bug: 512234
Was this only checked into the release tree for 1.9.0.14?
(Assignee)

Comment 36

8 years ago
yes, it's the only affected version.

Updated

8 years ago
Keywords: common-issue+
You need to log in before you can comment on or make changes to this bug.