Closed Bug 620723 Opened 14 years ago Closed 14 years ago

Using Minefield builds starting on Dec 20, 2010, and then going back to beta 7 loses bookmark icon thumbnails and history on startup

Categories

(Toolkit :: Places, defect)

Product:
Toolkit
Component:
Places
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: notforyourmail, Unassigned)

References

Details

(Keywords: relnote) 

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9pre) Gecko/20101220 Firefox/4.0b9pre
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9pre) Gecko/20101220 Firefox/4.0b9pre

All bookmark icons are displaying with a blank white icon instead of the correct icon.  The icons are rebuilt on most sites (but not cnn.com or news.com) as those sites are browsed.  Restarting in the Firefox Beta, then in Minefield wipes them out again.

Reproducible: Always

Steps to Reproduce:
1.  Bookmark some pages.  
2.  Quit minefield and run FF Beta 7.
3.  Quit FF Beta 7 and restart Minefield.
4.  Bookmark icons are all white.
Actual Results:  
Bookmark icons are all white.

Expected Results:  
Bookmark icons show the favicon for each site.
this is known, you cannot move across beta9 (or current minefield) to beta 7.
beta 8 is fine, 3.6.x is fine.

We cannot fix this problem since we cannot go back in time.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Component: General → Places
Product: Firefox → Toolkit
QA Contact: general → places
Resolution: --- → WONTFIX
There does not appear to be a Beta 8 available.  Beta 7 claims there are no updates available.  The Beta download page also downloads Beta 7.  Perhaps there is a labeling issue, but it looks like *everyone* who downloads the latest beta for Mac will be downloading Beta 7, and will have their profile corrupted if they switch between that one and Minefield.  (A warning about the problem with moving between the two would be very valuable here!)
we cannot add a warning, as I said, because we cannot go back in time.
I don't think a lot of users will install minefield and then go back to beta7, there is really no reason, and beta8 will be out today or tomorrow.
I often have to go back to a FF beta when there is a major bug in the latest nightly build.  For example, the current build does not repaint any new window until I move that window, and has been causing me problems.  Also, here's a very real world scenario in which this will catch someone (as it happens to me):

1) You use Minefield as your primary browser and keep it updated.
2) You have a copy of FF Beta that you also use (see above), but you run it infrequently because Minefield is your primary browser.  Therefore, it may not update itself for a while.
3) You now have an older Beta (say, Beta 7), and the latest Minefield.
4) When you run the older Beta to update it, you get the corruption problem.

ie. This could hit anyone who updates through the browser itself rather than downloading a fresh image, if they run the older beta simply to update to the newer beta!
(In reply to comment #3)
> There does not appear to be a Beta 8 available.  Beta 7 claims there are no
> updates available.  The Beta download page also downloads Beta 7.  Perhaps
> there is a labeling issue, but it looks like *everyone* who downloads the
> latest beta for Mac will be downloading Beta 7, and will have their profile
> corrupted if they switch between that one and Minefield.  (A warning about the
> problem with moving between the two would be very valuable here!)
Beta 8 is coming out today.  Using nightly builds always is dangerous and it is cleared stated on nightly.mozilla.org that "These builds are for testing purposes only."
Status: RESOLVED → VERIFIED
Right.  What I'm saying is that even after Beta 8 is released, someone who goes to Beta 7 to *update* to Beta 8, after running the daily build, will have their profile corrupted.  If you only run the beta or only run Minefield this won't happen.  If you only update the beta by downloading the .dmg file from Mozilla's servers, this won't happen.  But if you update through the browser itself (a perfectly legitimate way to update, and the one that many testers probably use), it's guaranteed to happen!

Furthermore, it will happen to users who, for whatever reason, restores an older version of their browser, not expecting this to happen.
(In reply to comment #7)
> Right.  What I'm saying is that even after Beta 8 is released, someone who goes
> to Beta 7 to *update* to Beta 8, after running the daily build, will have their
> profile corrupted.  If you only run the beta or only run Minefield this won't
> happen.  If you only update the beta by downloading the .dmg file from
> Mozilla's servers, this won't happen.  But if you update through the browser
> itself (a perfectly legitimate way to update, and the one that many testers
> probably use), it's guaranteed to happen!
beta 7 -> beta 8 should *not* throw anything away.  There were no database changes in beta 8.  beta 8 -> nightly is also fine because we landed a fix for the issue before beta 8 was complete.  Additionally, 3.6 -> nightly is also fine (with beta 7 or beta 8 in between).

I don't understand what you mean by "if you update through the browser itself it's guaranteed to happen" when you also say "If you only run the beta or only run Minefield this won't happen".  The code is no different in either case.

> Furthermore, it will happen to users who, for whatever reason, restores an
> older version of their browser, not expecting this to happen.
Only if they go back to something beta 7 or earlier.  It isn't exactly something we support.
Maybe I'm misunderstanding you?  Here's what I'm trying to say:

Before updating, user has the following on their machine:
Beta 7, latest daily build.

User runs the daily build.  The database is updated.  Note that the user still has Beta 7 on their machine.  ie. One daily browser and one "stable" browser.

Now Beta 8 comes out.  The user has two choices if they still want to maintain both the Beta and Minefield on their machine:
1) Download the Beta directly.
2) Go to the Firefox menu, and select "check for updates".  This is a valid way to update the Beta to the latest Beta version.  (This is what I mean by updating through the browser itself.)

If they do #1, they're fine, because Beta 7 won't run again.  But if they've already run Minefield, and then they run Firefox B7, attempting to update to B8, then they are guaranteed to corrupt their profile.

In other words, the user is updating the beta in the way the beta is designed to be updated.  But doing so causes them to "go back in time", as you described it.

ie.  This is OK:
Beta 7 -> Beta 8 -> Beta n

and this is OK:

Beta 7 -> Minefield -> always stick with Minefield

But this is going to corrupt the profile:

Beta 7 & Minefield -> Beta 7 & latest Minefield -> run Beta 7 to update to Beta 8.

The corruption case occurs where you have a user who normally keeps a daily build and a beta release up to date on their machine, and that user uses the browser itself to update to the latest version of the browser rather than downloading a fresh copy, AND updates the daily build first, because updating the daily build changes the database format, and running the user's current beta version to update itself causes the user to "revert" to a version using the older database.
If you don't believe me, please see the comments on the Slashdot story for the Beta 8 release at http://news.slashdot.org/article.pl?sid=10/12/21/1712244 and search for the following, from another user who appears to have run into the same issue:

"    The URL bar now drops down a list of random URLs that has absolutely no relation to anything I have recently entered manually.

    They're not random, they're your most visited sites.

No they're not. I just dropped down the list and one of the the items is from about a week ago and all the rest are much older. It isn't showing recent browsing history, it isn't showing URLs I've recently typed in manually. It isn't showing anything even remotely useful."
OK, we are basically saying the same thing.  Using a nightly and a beta with the same profile isn't safe (never has been) even if it generally is OK.  You could use Sync and two different profiles and not have to worry about this too much if you really wanted to.
We can maybe add a release note, not that people generally read them...
Keywords: relnote
I'll add it to the beta 8 release notes.
It's a start.  :-)

Speaking of which, I'm not sure if this should be a different bug or not, but when I tried to restore my corrupted profile from an earlier version (via Time Machine backups), I wound up with a *blank* profile.  Time Machine restored the folder from a previous time that should have been safe, because it was several days before the corruption problem occurred.  The profile name was identical.  But it restored with no bookmarks or extensions.  I was able to recover by copying over a copy of the profile from a different machine that was originally cloned from the one with the corrupted profile.  But an easy method of reverting or restoring a corrupted profile that an ordinary user would understand (or better - that would be transparent to an ordinary user) would be really useful.  I can imagine that a user who uses Sync and gets a corrupted profile may wind up with *all* devices having corrupted profiles.
this was planned to be added to the beta9 relnotes, I'm not sure it is really useful to put it beta8 since beta8 does not break anything... btw if we put the relnote in both betas, it will work as well.
If you run beta 8 and post-places landing nightlies you hit this...so I think this is appropriate for beta 8 notes as well. Please let me know if I don't understand when this issue arises though.
(In reply to comment #16)
> If you run beta 8 and post-places landing nightlies you hit this...so I think
> this is appropriate for beta 8 notes as well. Please let me know if I don't
> understand when this issue arises though.

no, beta 8 is fine.

the problem happens only if you downgrade any build >= 20101210 to a build < 20101210.

beta 8 can downgrade to whatever
beta 9 can downgrade to beta 8 (but not to beta7)
trunk can downgrade to beta 8 (but not to beta7)
all betas can downgrade to 3.6.x
ehm sorry the problem happens "if you downgrade any build >= 20101216 (Places branch merge) to a build < 20101210 (fix to central for databse corruption)"
Ah, thanks for clarifying. I'll yank it out of the relnotes for beta 8 when I get time.
Morphing this to be a bit more generic in hopes of having one place for all these issues to be duplicated to.
Summary: Minefield builds starting on Dec 20, 2010 lose bookmark icon thumbnails on startup → Using Minefield builds starting on Dec 20, 2010, and then going back to beta 7 loses bookmark icon thumbnails and history on startup
This is not something I remember hearing warnings about, despite hanging out on IRC and reading Planet Mozilla (maybe I missed it).  Guess I don't feel like it's common knowledge.  Especially because many had said that they had no problems switching between 3.6 & 4.0 nightlies or beta on the same profile.
Perhaps we can add a warning somewhere. (Maybe someone could at least blog about it or there could be a suggestions about profiles at the download page.)
I think the best place for a warning would be in the window that pops up asking you to restart the browser to update it.  When a new nightly (or other update) comes out, I don't go to the mozilla website.  I know it's out because the browser downloads it for me and asks me to restart to update.  So if an update is likely to cause problems, the place where you would catch all users who update automatically would be the update window.  A good way to do it would be to put a big warning icon on it, and a message indicating the problem that could be caused by the update (such as - if you run this, do not switch back to beta 7 or earlier).  Or, before converting the database to the new format, create a backup snapshot of the user's profile that can be used to restore from, or to switch to earlier versions.  In other words:

1) A user should always be notified of changes that could result in data loss, and any steps they need to take to avoid it.
2) Situations that could result in data loss should always be easily and (preferably) transparently recoverable.
OS: Mac OS X → All
Hardware: x86 → All
my bug has been marked as a duplicate for this, but I never have tried Minefield nor the FF betas.

When I upgrade from Firefox 3.6.15 to Firefox 4, my browsing history is lost.
In the profile folder, Firefox 4 creates a places.sqlite.corrupt file, with my
old history; but this doesn't get imported.

I have history for months of browsing, and losing it would be annoying.

PS: When looking in detail to the differences between the two sqlite files, I
see new columns called "guid" have been added to two tables between Firefox
3.6.15 and 4.

Reproducible: Always

Steps to Reproduce:
1. Have browsing history in Firefox 3.6.15
2. Install Firefox 4
3. Open Firefox 4's history
Actual Results:  
History is empty

Expected Results:  
History should have been converted and imported
(In reply to comment #26)
> my bug has been marked as a duplicate for this, but I never have tried
> Minefield nor the FF betas.
Your bug was wrongly marked as a duplicate.  It's been reopened (sorry about that!).
No problem :)
You need to log in before you can comment on or make changes to this bug.