Make LocalStorage persistent

This CL is doing a bunch of Misc work to make LocalStorage data persist.

First of all, this allows WebKit clients to specify whether or not the VFS should be used.  In the browser process, we never want it to be.

Next, this allows WebKit clients to specify the behavior of WebKit's FileSystem code.  By default, they should all be NOT_REACHED().  The browser process implements the two of these I need for LocalStorage, but it'll be really easy for the rest to be implemented as needed.

Next, this adds a function that storage routines can call to ensure that lazily initialized stuff that must be initialized on the main WebKit thread is initialized.  Right now, this is just used to initialize the UTF8 conversion tables, but I'm sure there'll be more overt time.

Lastly, this uses the profile directory stored by webkit_context_ to derive the path LocalStorage should use.

This CL also cleans up a few minor style issues as it goes.

TEST=none
BUG=4360
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=22452

[jorlow, 2009-08-03 22:02:45]

I think this is ready for review.

[darin (slow to review), 2009-08-04 18:16:24]

http://codereview.chromium.org/159778/diff/1075/1084
File chrome/browser/in_process_webkit/browser_webkitclient_impl.cc (right):

http://codereview.chromium.org/159778/diff/1075/1084#newcode70
Line 70: WebKit::WebString BrowserWebKitClientImpl::pathByAppendingComponent(
I think this method should just be implemented in WebKitClientImpl. 
pathByAppendingComponent may also be something that is not worth bridging out of
WebCore for.  Hmm...

http://codereview.chromium.org/159778/diff/1075/1086
File chrome/renderer/renderer_webkitclient_impl.cc (right):

http://codereview.chromium.org/159778/diff/1075/1086#newcode52
Line 52: return true;
hmm... this is not always true.  it might be good to define a global variable
that we set to true if EnableSandbox is called in renderer_main.cc.

http://codereview.chromium.org/159778/diff/1075/1082
File webkit/api/public/WebKitClient.h (right):

http://codereview.chromium.org/159778/diff/1075/1082#newcode92
Line 92: virtual WebString directoryName(const WebString& path) = 0;
directoryName and pathByAppendingComponent really just manipulate path strings. 
they don't require filesystem access, so the sandbox doesn't require them to be
here.  they probably should be implemented directly in FileSystemChromium.cpp.

http://codereview.chromium.org/159778/diff/1075/1081
File webkit/api/src/WebKit.cpp (right):

http://codereview.chromium.org/159778/diff/1075/1081#newcode77
Line 77: WebCore::UTF8Encoding();
I think we can just add this to 'initialize' so that we don't need
initializeStorage.  Let's keep the API simple.

[jorlow, 2009-08-04 22:31:18]

I'm pretty happy with things now.  Take another look?

http://codereview.chromium.org/159778/diff/1075/1084
File chrome/browser/in_process_webkit/browser_webkitclient_impl.cc (right):

http://codereview.chromium.org/159778/diff/1075/1084#newcode70
Line 70: WebKit::WebString BrowserWebKitClientImpl::pathByAppendingComponent(
On 2009/08/04 18:16:25, darin wrote:
> I think this method should just be implemented in WebKitClientImpl. 
> pathByAppendingComponent may also be something that is not worth bridging out
of
> WebCore for.  Hmm...

Done.

http://codereview.chromium.org/159778/diff/1075/1086
File chrome/renderer/renderer_webkitclient_impl.cc (right):

http://codereview.chromium.org/159778/diff/1075/1086#newcode52
Line 52: return true;
On 2009/08/04 18:16:25, darin wrote:
> hmm... this is not always true.  it might be good to define a global variable
> that we set to true if EnableSandbox is called in renderer_main.cc.

Done.

http://codereview.chromium.org/159778/diff/1075/1082
File webkit/api/public/WebKitClient.h (right):

http://codereview.chromium.org/159778/diff/1075/1082#newcode92
Line 92: virtual WebString directoryName(const WebString& path) = 0;
On 2009/08/04 18:16:25, darin wrote:
> directoryName and pathByAppendingComponent really just manipulate path
strings. 
> they don't require filesystem access, so the sandbox doesn't require them to
be
> here.  they probably should be implemented directly in FileSystemChromium.cpp.

We talked about this.  There isn't a very good way to do it without calling into
Chrome.

http://codereview.chromium.org/159778/diff/1075/1081
File webkit/api/src/WebKit.cpp (right):

http://codereview.chromium.org/159778/diff/1075/1081#newcode77
Line 77: WebCore::UTF8Encoding();
On 2009/08/04 18:16:25, darin wrote:
> I think we can just add this to 'initialize' so that we don't need
> initializeStorage.  Let's keep the API simple.

Done.

[darin (slow to review), 2009-08-04 23:21:30]

LGTM

http://codereview.chromium.org/159778/diff/223/1175
File webkit/api/public/WebKitClient.h (right):

http://codereview.chromium.org/159778/diff/223/1175#newcode34
Line 34: #include <ctime>
nit: we usually just include time.h

http://codereview.chromium.org/159778/diff/223/1175#newcode86
Line 86: // Most of these have NOT_REACHED() asserts unless running in the
browser process.
nit: this comment is a bit out of place... it refers to an implementation that
does not exist at the WebKit API level.  also, the concept of a separate browser
process may not make much sense to other embedders of WebKit.

http://codereview.chromium.org/159778/diff/223/1175#newcode180
Line 180: // Returns whether or not we should act as though the sandbox is
this is a great comment, but i'm a bit torn since it refers to a lot of chrome
specific things.  can you generalize it a bit more?  (i'm torn b/c this is a
great comment.)