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

Re: Resending Re: WebStorage and WebDatabase - creation and exceptions

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 21 Sep 2009 11:45:11 -0700
Message-ID: <63df84f0909211145y2837d45fpb50f5285f740144c@mail.gmail.com>
To: "Nikunj R. Mehta" <nikunj.mehta@oracle.com>
Cc: public-webapps WG <public-webapps@w3.org>
On Mon, Sep 21, 2009 at 9:45 AM, Nikunj R. Mehta
<nikunj.mehta@oracle.com> wrote:
> There was no response to this earlier, so resending it. Please answer the
> question:
>
> why allow browsers to selectively block out WebDatabase and not other kinds
> of storage?
>
> Nikunj
> On Aug 31, 2009, at 11:07 AM, Nikunj R. Mehta wrote:
>
> In WebDatabase:
>
> The user agent may raise a SECURITY_ERR exception instead of returning a
> Database object if the request violates a policy decision (e.g. if the user
> agent is configured to not allow the page to open databases).
>
> In WebStorage (emphasis mine):
>
> When a new HTMLDocument is created, the user agent must check to see if the
> document's top-level browsing context has allocated a session storage area
> for that document's origin. If it has not, a new storage area for that
> document's origin must be created.
>
> When the localStorage attribute is accessed, the user agent must check to
> see if it has allocated a local storage area for the origin of the Document
> of the Window object on which the method was invoked. If it has not, a new
> storage area for that origin must be created.
>
> A browser may not allow local storage for a certain origin, just like it may
> not allow cookies to be stored. What is the expected behavior in that case?
> Alternatively, why allow browsers to selectively block out WebDatabase and
> not other kinds of storage?

The inconsistency seems like an oversight to me.

Though I'm not sure what the correct way to do this is. It seems silly
to for *every* feature mention that the UA may do something different
if the user has opted to disable a feature for whatever reason. If I
as an implementor wanted to allow my users to disable
addEventListener, I would do so even if the spec doesn't explicitly
allow it.

On the other hand, it might be somewhat useful to give implementors a
hint on *how* to disable a feature if it decides to do so. For example
for addEventListener it might be appropriate to simply do nothing
rather than throw an exception.

/ Jonas
Received on Monday, 21 September 2009 18:46:11 GMT

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