User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20090729 Firefox/3.5.2 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) 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 ?
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)
Seems to happen updating from 3.0.13 to 3.5.2 via the pushed MU offer.
(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.
(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.
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.
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?
Can this block the next prompted MU?
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?
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.
> 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?
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.
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.
(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 220.127.116.11. This needs to land on CVS HEAD and on GECKO190_20090812_RELBRANCH. Approved for 18.104.22.168 and 22.214.171.124. a=ss for release-drivers
checked in on head and relbranch.
Do we have any tests in this area? Shall we add a Litmus / Mozmill test?
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.
RESOLVED FIXED since this was a 1.9.0-only issue.
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.
firstname.lastname@example.org: 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
Was this only checked into the release tree for 126.96.36.199?
yes, it's the only affected version.