Bug 15185 - Two different icon database schemas running side-by-side causes issues
Summary: Two different icon database schemas running side-by-side causes issues
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 523.x (Safari 3)
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2007-09-11 16:27 PDT by Brady Eidson
Modified: 2007-12-10 06:34 PST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brady Eidson 2007-09-11 16:27:56 PDT
http://trac.webkit.org/projects/webkit/changeset/25439 introduced a new schema to the icon database for performance reasons.

The side effect is that if you are running a WebKit with v6 schema side-by-side with a v5 schema, one of them will fail.

For example, a common problem is people launching a v6 WebKit, then launching a v5 WebKit.  The v5 WebKit will see the database version is wrong and overwrite it with its new schema.  The v6 WebKit will then attempt to make changes to the database.  Almost any sqlite operation it attempts will fail because the database has been reverted to v5.

The Safari 3 beta and the last few Leopard seeds fall into the v5 category, which makes running "stock Safari" at the same time as ToT WebKit problematic in these environments.

This shouldn't lead to any crashes, but missing icons and a lot of various ASSERTs may be triggered.

I propose that we make a change to WebKit such that if it sees the database version is "higher" than what it expects, it will disable the icon database.

For example, this would make a theoretical v7 database win out over a v6 database, because the v6 WebKit would know "someone newer than me has already touched this database, so I give up" and it closes itself
Comment 1 Brady Eidson 2007-09-11 17:02:34 PDT
<rdar://problem/5475639>
Comment 2 Brady Eidson 2007-09-11 17:28:37 PDT
Two possibilities here - probably both should be considered

A - revving the filename so v6 doesn't stomp over v5
B - making a change to the Icon database to gracefully shut down if it sees a newer version.  This would prevent the problem in the future with the same filename.