[whatwg] RFC: Alternatives to storage mutex for cookies and localStorage

[Chris Jones]

Jonas Sicking wrote:
> On Tue, Sep 8, 2009 at 1:38 PM, Chris Jones<cjones at mozilla.com> wrote:
>> No one has responded directly to my original proposal of making
>> |window.localStorage === undefined| until |window.transaction| or whatever
>> has been accessed.  Unlike your proposal and a similar one from Jeremy, mine
>> is a "safe" (non-racy) way for spec-compliant UAs to "bend" backwards
>> compatibility without explicitly breaking it.
> 
> How is that not breaking compatibility? Any existing pages will
> directly access window.localStorage to read/write data. Such pages
> would break with your proposal, no?
> 

I think I haven't been explaining my proposal clearly enough.  Let me 
try to err on the other side of brevity.  Sorry if this is too pedantic.

Currently, UAs either (i) support localStorage or (ii) don't.  Web apps 
using localStorage must therefore determine whether the UA they're 
running in supports localStorage, and adjust their behavior accordingly. 
  If they don't, they won't run in type (ii) UAs.

So how do web apps implement this check?  If I were implementing it, I 
would test |window.localStorage === undefined|.  I have no clue how web 
devs actually implement it; I solicited feedback from them in earlier posts.

Assuming that web apps test for |window.localStorage === undefined|, 
then let's explore the two possibilities for changing the localStorage 
API to include transactions.  If the spec were to add transactional 
localStorage, then UAs in the field would then fall into three classes 
(i) support transactional localStorage [compliant]; (ii) support 
non-transactional localStorage [non-compliant]; (iii) don't support 
localStorage at all [non-compliant].  Web apps would also fall into 
three classes (a) use transactional localStorage [compliant]; (b) use 
non-transactional localStorage [non-compliant]; (c) don't use 
localStorage [NA].

Note that web app type (c) is irrelevant to the discussion, since 
changes to the localStorage API don't affect them.

With my proposal, a web app that tests whether localStorage is available 
with |window.localStorage === undefined| would conclude that it's not, 
because that object would not be available until |window.transaction| or 
whatever was accessed.  In Jeremy's and Benjamin's proposals, a web app 
using that would check would conclude that window.localStorage *is* 
available.

Only type (b) web apps are affected by this difference.  In my proposal, 
  in type (i) browsers, type (b) web apps would conclude that 
localStorage was not supported and thus those web apps would not try to 
use it.  In other words, they would *not* break, just not use 
localStorage.  In Jeremy's and Benjamin's proposals, type (b) web apps 
would conclude that localStorage *is* supported, and would use it in a 
racy way (outside of transactions), to the detriment of themselves and UAs.

Type (c) web apps would need to use the check |window.transaction === 
undefined| to determine whether *transactional* localStorage was 
supported, and thus aren't affected by either proposal.

If this explication isn't clear, please let me know and I will construct 
a compatibility matrix based on (a), (b), (c), and (i), (ii), (iii).

The |window.localStorage === undefined|-check assumption is a big one 
(!).  If that's not how the compatibility check is done in the wild, 
then my proposal won't ameliorate the breakage of type (b) web apps.

Cheers,
Chris