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

[whatwg] Overriding functions in DOM Storage

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 22 May 2009 20:03:44 -0700
Message-ID: <EED4386A-1736-446D-9EDB-13088AE4B70E@apple.com>

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
Received on Friday, 22 May 2009 20:03:44 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:12 UTC