We need to update AsyncFileSystemChromium::crackFileSystemURL to use innerURL if it's present. Once http://codereview.chromium.org/7811006 lands, it always will, and we can remove the old code. Patch to follow shortly.
Created attachment 125675 [details] Patch
Comment on attachment 125675 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=125675&action=review > Source/WebKit/chromium/src/AsyncFileSystemChromium.cpp:67 > + String typeString = url.innerURL()->path().substring(1); There's probably a way to do this that saves some mallocs. If this is performance-sensitive code, we might want to investigate further.
Comment on attachment 125675 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=125675&action=review > Source/WebKit/chromium/src/AsyncFileSystemChromium.cpp:77 > + filePath = decodeURLEscapeSequences(url.path()); Not the innerURLs path?
Comment on attachment 125675 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=125675&action=review >> Source/WebKit/chromium/src/AsyncFileSystemChromium.cpp:67 >> + String typeString = url.innerURL()->path().substring(1); > > There's probably a way to do this that saves some mallocs. If this is performance-sensitive code, we might want to investigate further. I don't expect it to be worth optimizing; certainly not right now. >> Source/WebKit/chromium/src/AsyncFileSystemChromium.cpp:77 >> + filePath = decodeURLEscapeSequences(url.path()); > > Not the innerURLs path? Nope; the innerURL's path tells us which storage area ["/temporary" or "/persistent"], and the outer URL gets the virtual path.
Committed r106856: <http://trac.webkit.org/changeset/106856>