W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

Quota Management API error codes

From: Kinuko Yasuda <kinuko@google.com>
Date: Wed, 4 Jul 2012 15:02:33 +0900
Message-ID: <CAMWgRNYFc=mAFkhxyAGU+h6RJDb_q9V-uDRtY50-EVMZt6Rukw@mail.gmail.com>
To: Web Applications Working Group WG <public-webapps@w3.org>, Jochen Eisinger <jochen@chromium.org>
(Replying to a message I got separately)

Thanks for the feedback!

Hmm if a write fails because the UA does not grant any quota for the site I
think it must throw a QuotaExceeded exception, so that website authors or
the users could tell how they can re-enable writing to the storage (e.g. by
allowing the UA to give some quota).
It looks like it's also how DOM storage draft says for Storage.setItem()
behavior?
http://www.w3.org/TR/webstorage/#the-storage-interface
I'm going to update the draft to clarify the point.

On the other hand, if using the storage is disabled by a security policy it
could probably fail differently but at an earlier timing, e.g. returning
null or throw a Security error when localStorage attribute is accessed
(though the latter behavior seems to be disliked among website authors).
http://www.w3.org/TR/webstorage/#the-localstorage-attribute

---------- Forwarded message ----------
From: Jochen Eisinger <jochen@chromium.org>
Date: Tue, Jul 3, 2012 at 2:56 PM
Subject: Quota Management API error codes
To: public-webapps@w3.org


Hey,

while reading http://www.w3.org/TR/quota-api/#quota-handling-in-storage-apiI
wondered what the desired behavior was when the UA refuses to grant
any
quota? I think it would be nice to specify this in the standard.

E.g. currently WebKit will throw a QuotaExceeded exception when a page
tries to write to DOM storage when DOM storage is disabled, while Firefox
throws a Security exception on any access to DOM storage.
These inconsistencies make it difficult for website authors to write apps
that work when the user configured the UA to disable certain APIs

best
-jochen
Received on Wednesday, 4 July 2012 06:03:22 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:53 GMT