<div class="gmail_quote">I haven't decided for sure yet, but I was leaning towards either option #2 or option #3 for Chrome. �Option 5 seems like it'll be very confusing to apps. �It's possible it'll even have undesired consequences like websites popping up alerts or telling the user "you need to increase your quota" and not allowing them to use the app until they do. �Web developers already need to handle localStorage not being part of the DOM, localStorage having a 0 sized quota, and hitting the quota while running. �Why also make them assume that localStorage could be populated and read-only?</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">Another question is whether a user in a "private" browsing session would want an app to have access to existing storage at all. �I can see arguments both ways.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">The most important thing, however, is to be consistent. �For example, if application cache was not read only but database was, then any application 'upgrading' its version in cache would fail while trying to upgrade the database schema. �Even when "schemas" are implicit (like in localStorage) this can be an issue. �Michael might have more to say on this.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">I also agree that it'd be ideal if all the browsers responded similarly. �If every browser implements it differently, it's much less likely that developers will properly test for this.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">I've inlined a couple additional comments...</div><div class="gmail_quote"><br></div><div class="gmail_quote">Jeremy</div><div class="gmail_quote"><br></div>
<div class="gmail_quote"><br></div><div class="gmail_quote">On Tue, Apr 7, 2009 at 5:24 PM, Brady Eidson <span dir="ltr"><<a href="mailto:beidson@apple.com">beidson@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
A commonly added feature in browsers these days is "private browsing mode" where the intention is that the user's browsing session leaves no footprint on their machine. �Cookies, cache files, history, and other data that the browser would normally store to disk are not updated during these private browsing sessions.<br>
<br>
This concept is at odds with allowing pages to store data on the user's machine as allowed by LocalStorage and Databases. �Surly persistent changes during a private browsing session shouldn't be written to the user's disk as that would violate the intention of a private browsing session.<br>
<br>
Let's take the specific case of LocalStorage, which is what I am currently working on with WebKit. �In attempting to fix this bug I came up with a few possible solutions:<br>
<br>
1 - Disable LocalStorage completely when private browsing is on. �Remove it from the DOM completely.<br>
2 - Disable LocalStorage mostly when private browsing is on. �It exists at window.localStorage, but is empty and has a 0-quota.<br>
3 - Slide a "fake" LocalStorage object in when private browsing is enabled. �It starts empty, changes to it are successful, but it is never written to disk. �When private browsing is disabled, all changes to the private browsing proxy are thrown out.<br>
4 - Cover the real LocalStorage object with a private browsing layer. �It starts with all previously stored contents. �Any changes to it are pretended to occur, but are never written to disk. �When private browsing is disabled, all items revert to the state they were in when private browsing was enabled and writing changes to disk is re-enabled.<br>
5 - Treat LocalStorage as read-only when private browsing is on. �It exists, and all previously stored contents can be retrieved. �Any attempt to setItem(), removeItem(), or clear() fail.<br>
<br>
Option 1 is simple but painful for applications to get such different behavior.<br>
Option 2 is only a little more complicated, but also seems unsatisfactory.<br>
Option 3 is simple to implement and option 4 would difficult to implement efficiently.</blockquote><div><br></div><div>Re #4: Most sites will not be given much space and you could implement copy-on-write, so I guess I only see this being an issue in a small minority of cases.</div>
<div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Both would lead to bizarre behavior where data that the application thought was saved really wasn't.</blockquote>
<div><br></div><div>This matches up with how most private browsing sessions handle cookies, right? �The data�persists�until the session is up (because some of the web can't work correctly without them) but then they're deleted at the end.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">For now we're going with option 5. �setItem() during private browsing will fail with the QUOTA_EXCEEDED_ERR the spec mentions. �removeItem() and clear() will silently fail, since the spec assumes they always succeed and doesn't provide a failure mechanism.<br>
<br>
It seems the same issues apply to all the storage mechanisms, be it LocalStorage, SessionStorage (with optional session resuming), and Databases.<br>
I have a few questions I think it would be wise for the spec to address for all of these:<br>
1 - What *should* the specified behavior be?<br>
2 - If read-only ends up being the specified behavior, should we have a mechanism for removeItem() and clear() to demonstrate that they failed?<br>
<br>
Thanks,<br><font color="#888888">
~Brady<br>
</font></blockquote></div><br><div><br></div>