Re: [webkit-dev] [webkit-changes] [43878] trunk/WebCore
+// FIXME: POST documents are always Reloads, but their subresources should still be Revalidate. I think the comment should say should still be Verify, unless actually reloading the page. +// If we bring the CachePolicy.h and ResourceRequest cache policy enums in sync with each other and +// remember Revalidate in ResourceRequests, we can remove this POST check and return either Reload +// or Revalidate if the DocumentLoader was requested with either. +const ResourceRequest request(documentLoader()-request()); +if (request.cachePolicy() == ReloadIgnoringCacheData ! equalIgnoringCase(request.httpMethod(), post)) +return CachePolicyRevalidate; + Will this work correctly for reloading a POSTed page? I think that it probably will, as the code below returns CachePolicyRevalidate anyway, but given the comment, I'm a bit confused. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] searching for documents
Hi everyone, I'm newer for Webkit. I'm interested in WebKit, and if _possible_, I intend to port it to our own OS (Not Linux but like Linux, at very beginning, it is ported from FreeBSD, and it has its own window system, not X11 etc). And now, to have a big picture in my mind, I'm trying to search some documents for WebKit architecture, however, I can not find what I want in the website for WebKit. What I want is documents or related for architecture design, brief description for each directory in source tree, or HOWTO port. Anyone can give suggestion? Any help will be greatly appreciated! Your friend, Sean ___ 好玩贺卡等你发，邮箱贺卡全新上线！ http://card.mail.cn.yahoo.com/___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Is that a bug of source-file distribution?
nbsp;Hi, guys. nbsp; I noticed the jsc project will execute the following nbsp;post-build events: nbsp; === if exist $(WebKitOutputDir)\buildfailed del $(WebKitOutputDir)\buildfailed nbsp; mkdir 2NUL $(WebKitOutputDir)\bin if exist $(WebKitLibrariesDir)\bin\icudt40.dll xcopy /y /d $(WebKitLibrariesDir)\bin\icudt40.dll $(WebKitOutputDir)\bin if exist $(WebKitLibrariesDir)\bin\icudt40$(LibraryConfigSuffix).dll xcopy /y /d $(WebKitLibrariesDir)\bin\icudt40 $(LibraryConfigSuffix).dll $(WebKitOutputDir)\bin if exist $(WebKitLibrariesDir)\bin\icuin40$(LibraryConfigSuffix).dll xcopy /y /d $(WebKitLibrariesDir)\bin\icuin40 $(LibraryConfigSuffix).dll $(WebKitOutputDir)\bin if exist $(WebKitLibrariesDir)\bin\icuuc40$(LibraryConfigSuffix).dll xcopy /y /d $(WebKitLibrariesDir)\bin\icuuc40 $(LibraryConfigSuffix).dll $(WebKitOutputDir)\bin if exist $(WebKitLibrariesDir)\bin\CoreFoundation$(LibraryConfigSuffix).dll xcopy /y /d $(WebKitLibrariesDir) \bin\CoreFoundation$(LibraryConfigSuffix).dll $(WebKitOutputDir)\bin if exist $(WebKitLibrariesDir)\bin\CoreFoundation.resources xcopy /y /d /e /i $(WebKitLibrariesDir) \bin\CoreFoundation.resources $(WebKitOutputDir)\bin\CoreFoundation.resources if exist $(WebKitLibrariesDir)\bin\pthreadVC2$(LibraryConfigSuffix).dll xcopy /y /d $(WebKitLibrariesDir)\bin\pthreadVC2 $(LibraryConfigSuffix).dll $(WebKitOutputDir)\bin if exist $(WebKitLibrariesDir)\bin\objc$(LibraryConfigSuffix).dll xcopy /y /d $(WebKitLibrariesDir) \bin\objc$(LibraryConfigSuffix).dll $(WebKitOutputDir)\bin === nbsp; After carefully checking of these commands, I find jsc trys to copy some .dll files which are not in webkit's source, in fact,nbsp;thenbsp;nbsp;$(WebKitLibrariesDir)\bin, at all. Such as icudt40.dll, icuin40.dll, icuuc40.dll, libxml2.dll, pthreadVC2.dll, and so on. nbsp; These xcopy actions will cause a building error, === error PRJ0019: A tool returned an error code from Performing Post-Build Event... === nbsp;which I have tested by removing all the xcopy commands from jscCommon.vsprops, and I got a Build: 18 succeeded, 0 failed, 0 up-to-date, 0 skipped. nbsp; Also, I found EXEs in $(WebKitOutputDir)\bin, such as WinLauncher.exe, couldn't work without these .dll files. nbsp; So, is that a bug or just an oblivion of forgetting to produce these .dll files in $(WebKitOutputDir)\bin , or maybe forgetting to provide them in $(WebKitLibrariesDir)\bin ? nbsp; nbsp;___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] searching for documents
hmmm, im looking for those docs a couple of months ago, no good though. You may want to take a look at WebKit/Gtk wiki notes and also, you may search out the webkit mailinglist on some related topics in which you may find out the ideas. Actually, the webkit code looks decent to understand ,at least for a arthitecture overview, compared with mozilla huge source . Have fun :) 2009/5/20 守富 骆 luosho...@yahoo.com.cn Hi everyone, I'm newer for Webkit. I'm interested in WebKit, and if _possible_, I intend to port it to our own OS (Not Linux but like Linux, at very beginning, it is ported from FreeBSD, and it has its own window system, not X11 etc). And now, to have a big picture in my mind, I'm trying to search some documents for WebKit architecture, however, I can not find what I want in the website for WebKit. What I want is documents or related for architecture design, brief description for each directory in source tree, or HOWTO port. Anyone can give suggestion? Any help will be greatly appreciated! Your friend, Sean -- 好玩贺卡等你发，邮箱贺卡全新上线！http://cn.rd.yahoo.com/mail_cn/tagline/card/*http://card.mail.cn.yahoo.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Libcurl backend build error (was: build on ubuntu not working as expected)
Hi, That is something reproducible by every one who builds libcurl as network backend in a non-debug build, and really has to be fixed. Code looks like this: (...) WebCore/platform/network/curl/ResourceHandleManager.cpp #ifndef NDEBUG char* url = 0; curl_easy_getinfo(d-m_handle, CURLINFO_EFFECTIVE_URL, url); fprintf(stderr, Curl ERROR for url='%s', error: '%s'\n, url, curl_easy_strerror(msg-data.result)); #endif if (d-client()) d-client()-didFail(job, ResourceError(String(), msg-data.result, String(url), String(curl_easy_strerror(msg-data.result; (...) NOTE: url is declared inside the IFNDEF and used if the if statement outside that, which is obviously wrong. Problem: I build revision 41937 sometime back and wxBrowser and my own wxPython browser was working fine Today i updated to revision 43688. 1. First I got an error at line 329 platform/network/curl/ResourceHandleManager.cpp url not defined in this scope so i moved out char* url out of #ifndef NDEBUG -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Libcurl backend build error (was: build on ubuntu not working as expected)
Hi Antonio, Yes, I've fixed it now, sorry. Thanks, Kevin On May 20, 2009, at 5:41 AM, tonikitoo (Antonio Gomes) wrote: Hi, That is something reproducible by every one who builds libcurl as network backend in a non-debug build, and really has to be fixed. Code looks like this: (...) WebCore/platform/network/curl/ResourceHandleManager.cpp #ifndef NDEBUG char* url = 0; curl_easy_getinfo(d-m_handle, CURLINFO_EFFECTIVE_URL, url); fprintf(stderr, Curl ERROR for url='%s', error: '%s'\n, url, curl_easy_strerror(msg-data.result)); #endif if (d-client()) d-client()-didFail(job, ResourceError(String(), msg-data.result, String(url), String(curl_easy_strerror(msg-data.result; (...) NOTE: url is declared inside the IFNDEF and used if the if statement outside that, which is obviously wrong. Problem: I build revision 41937 sometime back and wxBrowser and my own wxPython browser was working fine Today i updated to revision 43688. 1. First I got an error at line 329 platform/network/curl/ResourceHandleManager.cpp url not defined in this scope so i moved out char* url out of #ifndef NDEBUG -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Memory Management of Webkit on MacOS
On May 20, 2009, at 9:33 AM, Lucius Fox wrote: Sorry. I meant does Webkit on MacOS X uses 'reference counted or garbage collected' memory management? Both. For Objective-C objects it uses whatever mode of memory management the host application chooses. This is also how Mac OS X system frameworks like AppKit behave. For its own non-Objective-C objects it uses both reference counting and garbage collection. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Memory Management of Webkit on MacOS
On May 20, 2009, at 10:11 AM, Darin Adler wrote: On May 20, 2009, at 9:33 AM, Lucius Fox wrote: Sorry. I meant does Webkit on MacOS X uses 'reference counted or garbage collected' memory management? Both. For Objective-C objects it uses whatever mode of memory management the host application chooses. This is also how Mac OS X system frameworks like AppKit behave. For its own non-Objective-C objects it uses both reference counting and garbage collection. And the underlying WebCore C++ code uses both manual new/delete, and reference counting via the RefPtr class. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Memory Management of Webkit on MacOS
On Fri, May 15, 2009 at 10:22 AM, Darin Adler da...@apple.com wrote: The WebKit framework on Mac OS X supports either mode, reference counted or garbage collected, depending on the mode of the application it’s linked to. -- Darin Thanks. Sorry. I meant does Webkit on MacOS X uses 'reference counted or garbage collected' memory management? Not 'if my MacOS application which uses Webkit can use 'reference counted or garbage collected' memory management? Thank you. On Fri, May 15, 2009 at 10:22 AM, Darin Adler da...@apple.com wrote: The WebKit framework on Mac OS X supports either mode, reference counted or garbage collected, depending on the mode of the application it’s linked to. -- Darin Thanks. Sorry. I meant does Webkit on MacOS X uses 'reference counted or garbage collected' memory management? Not 'if my MacOS application which uses Webkit can use ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] compiling the jsc alone
Hi, I tried to compile the JavaScriptCore alone using the Scripts/build-jsc script but I've found that the script does nothing when building for GTK. Is there any other way to do that? regards. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] DOM Storage and private browsing
I'm pretty confused by the policy decisions in DOM Storage with respect to private browsing. When in private browsing, both LocalStorage and SessionStorage return QUOTA_EXCEEDED_ERR whenever setItem() is called and simply ignore removeItem() and clear() calls. This is different from the behavior when LocalStorage persistence is disabled (because page-settings()-localStorageDatabasePath() returns nothing) which returns a LocalStorage object that is not database backed. According to a FIXME in LocalStorage::fullDatabaseFilename [2], there's also plans to allow LocalStorage (but just not back it with a database) when there is no quota. The first question is why private browsing affects SessionStorage? The original email [1] on the matter didn't mention changing this, and I can't see any reason why it needs to. Next, why the (planned) inconsistency in quota handling? This seems to go against the Apple view on LocalStorage persistence ([doing this] would lead to bizarre behavior where data that the application thought was saved really wasn't is the only example I could find in 1 minute, but I believe there's others in [3] and other threads). It also seems confusing that the script would get a QUOTA_EXCEEDED_ERR if there's a tiny quota but would just get a non-database backed storage if there's 0 quota. Lastly, I have to ask (at the risk of rehashing [3]) why private browsing gives access to data accumulated before entering private browsing (which could be sensitive and user identifying!) and why it's considered ok to silently ignore requests to clear/remove data (even though it's not OK according to [1] to offer a non-persistent LocalStorage). I'm sorry if these questions sound antagonistic, but I just want to understand what the overall way of thinking/vision is here. Just to be clear, I understand that Safari's private browsing has a different philosophy from Chromium's incognito mode. I'm bringing this up because (as far as I can tell) WebKit is not consistent internally. If any changes need to be made as a result of this discussion, I'm happy to make them. :-) Jeremy [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-April/019238.html [2] http://svn.webkit.org/repository/webkit/trunk/WebCore/storage/LocalStorage.cpp [3] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-April/thread.html#19238 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOM Storage and private browsing
On May 20, 2009, at 1:03 PM, Jeremy Orlow wrote: I'm pretty confused by the policy decisions in DOM Storage with respect to private browsing. Just to be clear, I understand that Safari's private browsing has a different philosophy from Chromium's incognito mode. Right. To re-clarify for this discussion: WebKit's private browsing feature exists as direct result of the design of Safari's private browsing feature from many years ago. Safari's private browsing feature has always been about do not leave any local footprint on the user's disk pertaining to this browsing session and has never been about creating an anonymous profile for the wild. Take a look at cookies, for example - a private browsing session starts with an in-memory copy of the cookies that existed at the time the session starts. Any changes to cookies during the session are not persisted to disk. When the private browsing session is over, we revert back to the stored cookies as they existed when private browsing began. We definitely discussed applying that model to LocalStorage, and it's certainly not off the table to do so. But such a solution would be much more complex, and were more concerned with closing the LocalStorage changes are written to disk during private browsing bug in the meantime. When in private browsing, both LocalStorage and SessionStorage return QUOTA_EXCEEDED_ERR whenever setItem() is called and simply ignore removeItem() and clear() calls. This is different from the behavior when LocalStorage persistence is disabled (because page- settings()-localStorageDatabasePath() returns nothing) which returns a LocalStorage object that is not database backed. I think this is a bug. The crux of the emails to whatwg that you reference is that we have two strong convictions: 1 - LocalStorage is guaranteed to be persistent. We're giving web developers simple, reliable, persistent storage and we plan to treat it like user data that only the controlling web apps or users themselves can make decisions about 2 - Since LocalStorage is guaranteed to be persistent, we should never give a web app the indication that we've stored some data when we actually have no intention to store it. If we can get a LocalStorage object that is not database backed, this goes against that philosophy and is a potential bug. According to a FIXME in LocalStorage::fullDatabaseFilename [2], there's also plans to allow LocalStorage (but just not back it with a database) when there is no quota. The first question is why private browsing affects SessionStorage? The original email [1] on the matter didn't mention changing this, and I can't see any reason why it needs to. From the ChangeLog for r42302 - ...made the change to restrict SessionStorage to read-only, also, with the understanding that the spec allows for SessionStorage to persist across relaunches, even though our implementation currently doesn't do this. This may have been overzealous preparation for the future, but hopefully it explains the thinking behind it. Next, why the (planned) inconsistency in quota handling? This seems to go against the Apple view on LocalStorage persistence ([doing this] would lead to bizarre behavior where data that the application thought was saved really wasn't is the only example I could find in 1 minute, but I believe there's others in [3] and other threads). It also seems confusing that the script would get a QUOTA_EXCEEDED_ERR if there's a tiny quota but would just get a non- database backed storage if there's 0 quota. As said above, if we can't back a LocalStorage object with a database, we shouldn't be pretending to store data in it. This is a bug. Same with 0 quota. It should probably end up having the read-only behavior as currently implemented for private browsing. Lastly, I have to ask (at the risk of rehashing [3]) why private browsing gives access to data accumulated before entering private browsing (which could be sensitive and user identifying!) and why it's considered ok to silently ignore requests to clear/remove data (even though it's not OK according to [1] to offer a non-persistent LocalStorage). I'm bringing this up because (as far as I can tell) WebKit is not consistent internally. If any changes need to be made as a result of this discussion, I'm happy to make them. :-) I started out with a description of Safari's Private Browsing philosophy then clarified a few points on our LocalStorage philosophy. Hopefully that - combined with the acknowledgement of some bugs! - clears up the inconsistencies. ;) As far as silently ignoring requests to clear/remove data - I personally hate the fact that we silently ignore such requests. One intent of my original email to whatwg was to get a mechanism to ignore these requests LOUDLY. But unlike the setItem() case where the spec gave us an out in the
Re: [webkit-dev] DOM Storage and private browsing
Thanks a lot for the quick response. This does clear up a lot for me. Hopefully I'll send my first DOM Storage re-factoring [1] patch out in a day or two. Once the re-factoring is squared away, I'll try to tackle these inconsistencies. (And, a little further out, I'm hoping to add Quota support and memory reclamation code.) In the mean time I'll file a bug. Note that, with respect to some of these corner cases, I think Chromium's behavior may need diverge from the default WebKit behavior. (For example, incognito mode will be different from WebKit's private browsing.) That said, I think it should be pretty easy to handle these differences in a clean manner. Thanks, Jeremy [1] https://lists.webkit.org/pipermail/webkit-dev/2009-May/007684.html On Wed, May 20, 2009 at 1:38 PM, Brady Eidson beid...@apple.com wrote: On May 20, 2009, at 1:03 PM, Jeremy Orlow wrote: I'm pretty confused by the policy decisions in DOM Storage with respect to private browsing. Just to be clear, I understand that Safari's private browsing has a different philosophy from Chromium's incognito mode. Right. To re-clarify for this discussion: WebKit's private browsing feature exists as direct result of the design of Safari's private browsing feature from many years ago. Safari's private browsing feature has always been about do not leave any local footprint on the user's disk pertaining to this browsing session and has never been about creating an anonymous profile for the wild. Take a look at cookies, for example - a private browsing session starts with an in-memory copy of the cookies that existed at the time the session starts. Any changes to cookies during the session are not persisted to disk. When the private browsing session is over, we revert back to the stored cookies as they existed when private browsing began. We definitely discussed applying that model to LocalStorage, and it's certainly not off the table to do so. But such a solution would be much more complex, and were more concerned with closing the LocalStorage changes are written to disk during private browsing bug in the meantime. When in private browsing, both LocalStorage and SessionStorage return QUOTA_EXCEEDED_ERR whenever setItem() is called and simply ignore removeItem() and clear() calls. This is different from the behavior when LocalStorage persistence is disabled (because page-settings()-localStorageDatabasePath() returns nothing) which returns a LocalStorage object that is not database backed. I think this is a bug. The crux of the emails to whatwg that you reference is that we have two strong convictions: 1 - LocalStorage is guaranteed to be persistent. We're giving web developers simple, reliable, persistent storage and we plan to treat it like user data that only the controlling web apps or users themselves can make decisions about 2 - Since LocalStorage is guaranteed to be persistent, we should never give a web app the indication that we've stored some data when we actually have no intention to store it. If we can get a LocalStorage object that is not database backed, this goes against that philosophy and is a potential bug. According to a FIXME in LocalStorage::fullDatabaseFilename [2], there's also plans to allow LocalStorage (but just not back it with a database) when there is no quota. The first question is why private browsing affects SessionStorage? The original email [1] on the matter didn't mention changing this, and I can't see any reason why it needs to. From the ChangeLog for r42302 - ...made the change to restrict SessionStorage to read-only, also, with the understanding that the spec allows for SessionStorage to persist across relaunches, even though our implementation currently doesn't do this. This may have been overzealous preparation for the future, but hopefully it explains the thinking behind it. Next, why the (planned) inconsistency in quota handling? This seems to go against the Apple view on LocalStorage persistence ([doing this] would lead to bizarre behavior where data that the application thought was saved really wasn't is the only example I could find in 1 minute, but I believe there's others in [3] and other threads). It also seems confusing that the script would get a QUOTA_EXCEEDED_ERR if there's a tiny quota but would just get a non-database backed storage if there's 0 quota. As said above, if we can't back a LocalStorage object with a database, we shouldn't be pretending to store data in it. This is a bug. Same with 0 quota. It should probably end up having the read-only behavior as currently implemented for private browsing. Lastly, I have to ask (at the risk of rehashing [3]) why private browsing gives access to data accumulated before entering private browsing (which could be sensitive and user identifying!) and why it's considered ok to silently ignore requests to clear/remove data (even though it's not OK
Re: [webkit-dev] DOM Storage and private browsing
Oh, and I forgot to mention: given your philosophy on private browsing and the potential for session data being written to disk in the future, I think it's reasonable to disallow writing to SessionStorage while in private browsing mode. I'll add a comment in the StorageArea.cpp code explaining this decision. J On Wed, May 20, 2009 at 2:01 PM, Jeremy Orlow jor...@chromium.org wrote: Thanks a lot for the quick response. This does clear up a lot for me. Hopefully I'll send my first DOM Storage re-factoring [1] patch out in a day or two. Once the re-factoring is squared away, I'll try to tackle these inconsistencies. (And, a little further out, I'm hoping to add Quota support and memory reclamation code.) In the mean time I'll file a bug. Note that, with respect to some of these corner cases, I think Chromium's behavior may need diverge from the default WebKit behavior. (For example, incognito mode will be different from WebKit's private browsing.) That said, I think it should be pretty easy to handle these differences in a clean manner. Thanks, Jeremy [1] https://lists.webkit.org/pipermail/webkit-dev/2009-May/007684.html On Wed, May 20, 2009 at 1:38 PM, Brady Eidson beid...@apple.com wrote: On May 20, 2009, at 1:03 PM, Jeremy Orlow wrote: I'm pretty confused by the policy decisions in DOM Storage with respect to private browsing. Just to be clear, I understand that Safari's private browsing has a different philosophy from Chromium's incognito mode. Right. To re-clarify for this discussion: WebKit's private browsing feature exists as direct result of the design of Safari's private browsing feature from many years ago. Safari's private browsing feature has always been about do not leave any local footprint on the user's disk pertaining to this browsing session and has never been about creating an anonymous profile for the wild. Take a look at cookies, for example - a private browsing session starts with an in-memory copy of the cookies that existed at the time the session starts. Any changes to cookies during the session are not persisted to disk. When the private browsing session is over, we revert back to the stored cookies as they existed when private browsing began. We definitely discussed applying that model to LocalStorage, and it's certainly not off the table to do so. But such a solution would be much more complex, and were more concerned with closing the LocalStorage changes are written to disk during private browsing bug in the meantime. When in private browsing, both LocalStorage and SessionStorage return QUOTA_EXCEEDED_ERR whenever setItem() is called and simply ignore removeItem() and clear() calls. This is different from the behavior when LocalStorage persistence is disabled (because page-settings()-localStorageDatabasePath() returns nothing) which returns a LocalStorage object that is not database backed. I think this is a bug. The crux of the emails to whatwg that you reference is that we have two strong convictions: 1 - LocalStorage is guaranteed to be persistent. We're giving web developers simple, reliable, persistent storage and we plan to treat it like user data that only the controlling web apps or users themselves can make decisions about 2 - Since LocalStorage is guaranteed to be persistent, we should never give a web app the indication that we've stored some data when we actually have no intention to store it. If we can get a LocalStorage object that is not database backed, this goes against that philosophy and is a potential bug. According to a FIXME in LocalStorage::fullDatabaseFilename [2], there's also plans to allow LocalStorage (but just not back it with a database) when there is no quota. The first question is why private browsing affects SessionStorage? The original email [1] on the matter didn't mention changing this, and I can't see any reason why it needs to. From the ChangeLog for r42302 - ...made the change to restrict SessionStorage to read-only, also, with the understanding that the spec allows for SessionStorage to persist across relaunches, even though our implementation currently doesn't do this. This may have been overzealous preparation for the future, but hopefully it explains the thinking behind it. Next, why the (planned) inconsistency in quota handling? This seems to go against the Apple view on LocalStorage persistence ([doing this] would lead to bizarre behavior where data that the application thought was saved really wasn't is the only example I could find in 1 minute, but I believe there's others in [3] and other threads). It also seems confusing that the script would get a QUOTA_EXCEEDED_ERR if there's a tiny quota but would just get a non-database backed storage if there's 0 quota. As said above, if we can't back a LocalStorage object with a database, we shouldn't be pretending to store data in it. This is a bug. Same with 0 quota.
