RESOLVED FIXED 237044
Regression(r242729): m_origin in IDBDatabaseIdentifier is incorrect
https://bugs.webkit.org/show_bug.cgi?id=237044
Summary Regression(r242729): m_origin in IDBDatabaseIdentifier is incorrect
Sihui Liu
Reported 2022-02-22 09:56:41 PST
...
Attachments
Patch (25.40 KB, patch)
2022-02-22 16:31 PST, Sihui Liu
no flags
Patch (34.55 KB, patch)
2022-02-23 15:38 PST, Sihui Liu
no flags
Patch (32.39 KB, patch)
2022-02-24 16:26 PST, Sihui Liu
no flags
Patch (20.91 KB, patch)
2022-02-25 09:48 PST, Sihui Liu
no flags
Patch (20.43 KB, patch)
2022-02-25 10:07 PST, Sihui Liu
no flags
Sihui Liu
Comment 1 2022-02-22 16:31:08 PST
Sihui Liu
Comment 2 2022-02-23 15:38:28 PST
youenn fablet
Comment 3 2022-02-24 05:32:47 PST
Comment on attachment 453036 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=453036&action=review > Source/WebCore/ChangeLog:17 > + update databaseDirectoryRelativeToRoot function to make it find the correct storage path. It seems we should keep databaseDirectoryRelativeToRoot to provide version/top/opening. > Source/WebCore/ChangeLog:900 > +2022-02-22 Sihui Liu <sihui_liu@apple.com> Double ChangeLog > Source/WebKit/ChangeLog:418 > +2022-02-22 Sihui Liu <sihui_liu@apple.com> Double change log > Source/WebCore/Modules/indexeddb/IDBDatabaseIdentifier.cpp:38 > + , m_origin { WTFMove(mainFrameOrigin), WTFMove(openingOrigin) } Thanks for fixing this! > Source/WebCore/Modules/indexeddb/IDBDatabaseIdentifier.cpp:61 > String IDBDatabaseIdentifier::databaseDirectoryRelativeToRoot(const SecurityOriginData& topLevelOrigin, const SecurityOriginData& openingOrigin, const String& rootDirectory, const String& versionString) Can we pass a const ClientOrigin& here? > Source/WebCore/Modules/indexeddb/IDBDatabaseIdentifier.cpp:70 > + return FileSystem::pathByAppendingComponent(openingFrameDirectory, topLevelOrigin.databaseIdentifier()); Shouldn't we keep version/top/iframe structure and do the migration of folders version/iframe/top? > Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp:1613 > + FileSystem::closeFile(handle); It could be a one liner. > Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp:1631 > void NetworkProcessProxy::createSymLinkForFileUpgrade(const String& indexedDatabaseDirectory) Maybe we should rename to upgradeIfNeeded? > Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp:1637 > + if (!FileSystem::fileExists(oldVersionDirectory)) It does not seem consistent with: "If IndexedDB does not have version directory, the origin directory structure is correct". So we are moving the correct ancient to the incorrect but consistent with v0/v1? Should we do the reverse and move back v0/v1 to correct? Also, given reverseOriginForDirectoryIfPossible is destructive, we probably only want to execute it once. I do not see what guarantees that oldVersionDirectory will not exist anymore after calling reverseOriginForDirectoryIfPossible. Is it overkill to increase the IDB database version? > Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp:1642 > FileSystem::createSymbolicLink(indexedDatabaseDirectory, oldVersionDirectory); Usually we do only file changes in background thread. I guess this is fine since it will only happen once. > Source/WebKit/UIProcess/WebPageProxy.cpp:1162 > + Unnecessary. > Tools/TestWebKitAPI/Tests/WebKitCocoa/IndexedDBPersistence.mm:378 > + // Database file is moved to [IndexedDBDirectory]/v1/[OpeninigOrigin]/[TopOrigin]/. s/OpeninigOrigin/OpeningOrigin
Sihui Liu
Comment 4 2022-02-24 14:09:57 PST
Comment on attachment 453036 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=453036&action=review >> Source/WebCore/ChangeLog:17 >> + update databaseDirectoryRelativeToRoot function to make it find the correct storage path. > > It seems we should keep databaseDirectoryRelativeToRoot to provide version/top/opening. Sure, I will make a change. >> Source/WebCore/ChangeLog:900 >> +2022-02-22 Sihui Liu <sihui_liu@apple.com> > > Double ChangeLog Will remove. >> Source/WebKit/ChangeLog:418 >> +2022-02-22 Sihui Liu <sihui_liu@apple.com> > > Double change log Wil remove. >> Source/WebCore/Modules/indexeddb/IDBDatabaseIdentifier.cpp:38 >> + , m_origin { WTFMove(mainFrameOrigin), WTFMove(openingOrigin) } > > Thanks for fixing this! Np! >> Source/WebCore/Modules/indexeddb/IDBDatabaseIdentifier.cpp:61 >> String IDBDatabaseIdentifier::databaseDirectoryRelativeToRoot(const SecurityOriginData& topLevelOrigin, const SecurityOriginData& openingOrigin, const String& rootDirectory, const String& versionString) > > Can we pass a const ClientOrigin& here? Sure. >> Source/WebCore/Modules/indexeddb/IDBDatabaseIdentifier.cpp:70 >> + return FileSystem::pathByAppendingComponent(openingFrameDirectory, topLevelOrigin.databaseIdentifier()); > > Shouldn't we keep version/top/iframe structure and do the migration of folders version/iframe/top? Sure, I made a mistake in thinking that v0's origins are correct. My new plan is to reverse the wrong origins in v1, and we can keep the structure here. >> Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp:1613 >> + FileSystem::closeFile(handle); > > It could be a one liner. Sure. >> Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp:1631 >> void NetworkProcessProxy::createSymLinkForFileUpgrade(const String& indexedDatabaseDirectory) > > Maybe we should rename to upgradeIfNeeded? We don't actually upgrade here, but just add a new v0 directory; we do the upgrade (adding v1/ and moving files to v1/) in IDBStorageManager::migrateOriginData. >> Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp:1637 >> + if (!FileSystem::fileExists(oldVersionDirectory)) > > It does not seem consistent with: "If IndexedDB does not have version directory, the origin directory structure is correct". > So we are moving the correct ancient to the incorrect but consistent with v0/v1? Should we do the reverse and move back v0/v1 to correct? > > Also, given reverseOriginForDirectoryIfPossible is destructive, we probably only want to execute it once. > I do not see what guarantees that oldVersionDirectory will not exist anymore after calling reverseOriginForDirectoryIfPossible. > Is it overkill to increase the IDB database version? I made a mistake here by thinking only ancient files have correct origin: actually ancient files and v0/ files are correct; only v1/ files are not. I will make the according changes. Yes, it seems overkill to increase the version (v0, v1, v2), because we are about to migrate data to general storage directory. >> Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp:1642 >> FileSystem::createSymbolicLink(indexedDatabaseDirectory, oldVersionDirectory); > > Usually we do only file changes in background thread. I guess this is fine since it will only happen once. I am going to move this to a background thread in network process so the migration can be done in both WebKit and WebKitLegacy. >> Source/WebKit/UIProcess/WebPageProxy.cpp:1162 >> + > > Unnecessary. Will remove. >> Tools/TestWebKitAPI/Tests/WebKitCocoa/IndexedDBPersistence.mm:378 >> + // Database file is moved to [IndexedDBDirectory]/v1/[OpeninigOrigin]/[TopOrigin]/. > > s/OpeninigOrigin/OpeningOrigin Will change.
Sihui Liu
Comment 5 2022-02-24 16:26:18 PST
Sihui Liu
Comment 6 2022-02-25 09:48:09 PST
Sihui Liu
Comment 7 2022-02-25 10:07:27 PST
EWS
Comment 8 2022-02-25 15:46:56 PST
Committed r290532 (247812@main): <https://commits.webkit.org/247812@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 453227 [details].
Radar WebKit Bug Importer
Comment 9 2022-02-25 15:47:21 PST
Note You need to log in before you can comment on or make changes to this bug.