W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2009

[whatwg] Overriding functions in DOM Storage

From: Jeremy Orlow <jorlow@google.com>
Date: Tue, 26 May 2009 19:44:41 -0700
Message-ID: <5dd9e5c50905261944q38694e67t8c37515b9171bf2c@mail.gmail.com>
No one else (especially from Mozilla or Microsoft)?  I was hoping to get a
consensus here (and maybe even things spelled out more clearly in the spec),
so that all the implementations could be headed in the same direction.  :-)


On Fri, May 22, 2009 at 8:03 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On May 22, 2009, at 5:41 PM, Jeremy Orlow wrote:
>
>  What is the behavior of the following supposed to be?
>>
>> window.sessionStorage.removeItem = function(x) { alert("Wait, this
>> works?"); };
>> window.sessionStorage.removeItem('blah');
>> alert(typeof window.sessionStorage.removeItem);
>>
>> Safari shows 2 alerts, and the second one says 'function'.
>> IE8 says "object doesn't support this property or method" if line 2 isn't
>> commented out.  It returns type string when it is.
>> Mozilla also won't run if line 2 is there, but it returns type object for
>> line 3.
>>
>> It seems to me that if IE8's behavior is correct, those parameters should
>> be marked as read-only since overriding them could only be used to shoot
>> yourself in the foot.
>>
>> If Safari's implementation is correct (and it's good for the
>> implementations to be overridable), then I believe there needs to be some
>> safe way to make .clear() usable again.  (Otherwise, once you override
>> removeItem() and clear(), there's not really any way to recover.)  The spec
>> would also need to make it clear that removeItem, setItem, etc are special
>> and should not be serialized to disk.
>>
>> Apologies if this is clear in the spec and I somehow missed it.  But, if
>> not, I think a clarification might be necessary.
>>
>
> DOM methods are normally overridable. That would make the Safari behavior
> correct. If we want the behavior to be different in this case, then the spec
> should spell that out. Perhaps part of the issue here is that the definition
> of the [NameSetter] extended attribute in Web IDL doesn't make clear whether
> or not name setter behavior takes precedence over setting existing
> predefined attributes or methods.
>
> Regards,
> Maciej
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090526/f8c24b4e/attachment.htm>
Received on Tuesday, 26 May 2009 19:44:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:49 UTC