One more question: are there any use cases where setGroupName could occur after window.localStorage() had been called? If so, this seems like it could be a problem since a Storage object is only created on the first call to DOMWindow::localStorage() and then it's cached as a member variable in DOMWindow. This would mean that any page that calls window.localStorage() before setGroupName is called would not be using the same localStorageArea as a page that calls setGroupName first.
Also, is there any significance to setGroupName being reset to nothing during Page's destructor? Jeremy On Thu, May 7, 2009 at 8:07 PM, Jeremy Orlow <[email protected]> wrote: > On Thu, May 7, 2009 at 5:25 PM, Darin Adler <[email protected]> wrote: > >> On May 7, 2009, at 4:56 PM, Jeremy Orlow wrote: >> >> I'm continuing to work on https://bugs.webkit.org/show_bug.cgi?id=25376 and >>> noticed that the map of origins to localStorageAreas is owned by the >>> PageGroup class. I'm having a bit of trouble understanding what exactly >>> page groups are used for. >>> >> >> PageGroup exists so you can have multiple web pages in a single >> application that share state, including frame namespace, such as the >> multiple windows and tabs in Safari. >> >> Separate page groups allow other web views to be separate, allowing the >> same application to use WebKit for things that should be isolated from web >> browsing; for example Safari on Windows uses web views for things like >> Preferences and text input. >> >> This is exposed as part of the WebKit API on Mac OS X, with the >> setGroupName: method. >> >> It may be a useless concept for Chromium but it’s critical on Mac OS X. > > > Didn't mean to imply they were useless, at all. Was just trying to > understand their use. > > Thanks! > J >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
