492514 - Update from Firefox 3.0 uses the bookmarks.html from an old update 2.0->3.0

Status: RESOLVED INCOMPLETE

(Firefox :: Bookmarks & History, defect)

Description

[Stefan Scholl]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10
Build Identifier: Firefox 3.5b4 for MacOS X 10.5, Intel

After an update from 3.0.10 (MacOS X 10.5, Intel) to 3.5b4, Firefox showed me old bookmarks.

Checked against the old bookmarks.html and I can confirm that the update wasn't using the places.sqlite from 3.0.10, but the bookmarks.html which is a leftover from an older update from 2.0.0.x to 3.0.0.

The profile was never cleaned or created anew after the last update. No problems. Maybe that's the reason why nobody else was reporting this. (Discussed the problem in a German newsgroup about Mozilla browsers and reported it with Hendrix.)

Reproducible: Always



Expected Results:  
Showed me the bookmarks from my 3.0.10 profile (places.sqlite).

http://groups.google.com/group/mozilla.feedback.firefox/msg/7e6e2bffc6ba21f4

Comment 1

[Ria Klaassen (not reading all bugmail)]

In about:config, what is the value of browser.places.importBookmarksHTML ?
http://kb.mozillazine.org/About:config

Comment 2

[Stefan Scholl]

(In reply to comment #1)
> In about:config, what is the value of browser.places.importBookmarksHTML ?
> http://kb.mozillazine.org/About:config

The old browser:
browser.places.importBookmarksHTML;false

The new browser:
browser.places.importBookmarksHTML;false


The User-Agent for both:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.0.10) Gecko/2009042315 Firefox/3.0.10

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4

Comment 3

[Stefan Scholl]

Tried to reproduce it. Saved the profile away and started fresh with a Firefox 2.0.0.20. Bookmarked 3 sites. Then update to Firefox 3.0.10. Deleted 1 of the sites (and visited some more).

Update to Firefox 3.5b4 and the current bookmarks are used, not the 3 from the 2.0.0.20 install.

===> Sorry. Can't reproduce it with a fresh install.


Must be something with my profile. You can lower the importance or close the bug, if you want to.


InfoLister's (German) list of Extensions, Themes, and Plugins:

Letzte Aktualisierung: Tue, 12 May 2009 18:59:46 GMT

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.0.10) Gecko/2009042315 Firefox/3.0.10

*** Erweiterungen (aktiviert: 32, deaktiviert: 0; gesamt: 32)
Adblock Plus 1.0.2 
ColorZilla 2.0.2 
Dafizilla ViewSourceWith 0.4.1 
Delicious Bookmarks 2.1.041 
Deutsches Wörterbuch 1.0.1 
Digger 3.0 
DOM Inspector 2.0.3 
DownloadHelper 4.4 
DownThemAll! 1.1.3 
Firebug 1.3.3 
Firecookie 0.8 
Firefox PDF Plugin for Mac OS X 1.0.3 
Html Validator 0.8.5.6 
HttpFox 0.8.4 
Image Zoom 0.3.1 
InfoLister 0.10 
Linkification 1.3.6 
Linky 2.7.1 
Live HTTP headers 0.14 
Mouse Gestures Redox 2.0.3 
NoScript 1.9.2.6 
Read it Later 0.9945 
Sage-Too 1.0.1 
ScrapBook 1.3.3.9 
Screengrab 0.96.1 
Sitzungs-Manager 0.6.5 
SQLite Manager 0.4.8 
Stylish 1.0.1 
Tamper Data 10.1.0 
United States English Dictionary 3.0.3 
Web Developer 1.1.6 
YSlow 2.0.0b3 

*** Themes (1)
Default [ausgewählt]

*** Plugins
Default Plug-in
Firefox PDF Plugin for Mac OS X
Flip4Mac Windows Media Plugin  2.2.1
Java Embedding Plugin 0.9.6.4
QuickTime Plug-In 7.6
RealPlayer Plugin
Shockwave Flash
Verified Download Plugin

Comment 4

[Stefan Scholl]

Noticed that there's a places.sqlite.corrupt after the update. I can help myself by making a backup of the bookmarks and rereading them after the update. History is gone, though.

But what's puzzling me: I have no bookmarks related problems with Firefox 3.0.10. I've read the places.sqlite with the CLI tool and ran VACUUM. No problem. But still, Firefox 3.5b4 doesn't like my places.sqlite (22.2 MiB). Sorry, can't upload it here.

Comment 5

[Stefan Scholl]

I repeated a clean migration from Firefox 2.0.0.20 (fresh install, no profile) to Firefox 3.0.10. I compared the schema of places.sqlite from this clean install with my old one, which survived some updates from 3.0.0 up to 3.0.10. (Both give a "6" for "PRAGMA user_version;").

I repaired the differences:

DROP TABLE moz_dummy_table;
DROP INDEX moz_annos_attributesindex;
DROP INDEX moz_annos_place_idindex;
CREATE UNIQUE INDEX moz_annos_placeattributeindex ON moz_annos (place_id, anno_attribute_id);
CREATE INDEX moz_historyvisits_dateindex ON moz_historyvisits (visit_date);

Now everything works OK when I update from 3.0.10 to 3.5b4 with my old places.sqlite. Migration from schema version 6 to 8. No problems. Bookmarks and history survived.

My guess: Along 3.0.0 to 3.0.10 something went different than the migration method from schema version 6 to 7 or 7 to 8 expects. This could happen to users who will wait until the release of 3.5 before updating!

I'd suggest to make the migration methods (6 to 7 and 7 to 8) more robust. I've browsed the source and the migration methods do check for some cases, but not for all as it seem.

Comment 6

[Stefan Scholl]

Attachment: The clean schema of places.sqlite from a fresh install

This is from a fresh install without the old profile. Migrated from Firefox 2.0.0.20 to 3.0.10.

Comment 7

[Stefan Scholl]

Attachment: The old schema of places.sqlite from my old profile

This one is the result from all updates from Firefox 3.0.0 up to 3.0.10

There are some differences to the clean schema.

Comment 8

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

the fact schema is not the same after moving from 2.x -> 3.0.10 and from 2.x to 3.0 and 3.0.10 is worth to investigate before 3.5, sounds like something is missing in a migration step. Thanks for the analysis.

Comment 9

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

about your initial bug was probably due to some error in the migration or statup path... that caused us to consider the db as corrupt, and try to restore bookmarks from a backup. since a backup was not available we imported from bookmarks.html

Comment 10

[Stefan Scholl]

(In reply to comment #9)
> about your initial bug was probably due to some error in the migration or
> statup path... that caused us to consider the db as corrupt, and try to restore
> bookmarks from a backup. since a backup was not available we imported from
> bookmarks.html

The thing is, there are backups in the profile. The folder "bookmarkbackups" exists. I haven't checked the Firefox source, but maybe the problem is that the backups have the German localized name like "Lesezeichen-2009-05-17.json". The same name is used if you want to manually backup the bookmarks, which makes sense. But for automatic backups … don't know.

Comment 11

[Stefan Scholl]

(In reply to comment #10)
> backups have the German localized name like "Lesezeichen-2009-05-17.json". The
> same name is used if you want to manually backup the bookmarks, which makes
> sense. But for automatic backups … don't know.

That would be bug 445704 ;-)

Comment 12

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

do the schema changes for the profile that has done all the 3.0.0 => 3.0.10 if you close and reopen the browser... i see part of the schema is fixed on first quit.

Comment 13

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

but i can't see how moz_items_annos_itemattributeindex exists if also exists moz_annos_attributesindex, since on quit we detect the latter and replace it, at the same level where we create the former...

Comment 14

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

also if you upgrade both profiles to 3.5b4, what are the differences?

Comment 15

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

confirming to have this on the radar.

Comment 17

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

that code changed quite a bit so it's really hard to debug this bug on current code, sorry. I just hope the various changes fixed the problem.