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.  :-)<br>
<br><br><div class="gmail_quote">On Fri, May 22, 2009 at 8:03 PM, Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com">mjs@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5"><br>
On May 22, 2009, at 5:41 PM, Jeremy Orlow wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
What is the behavior of the following supposed to be?<br>
<br>
window.sessionStorage.removeItem = function(x) { alert("Wait, this works?"); };<br>
window.sessionStorage.removeItem('blah');<br>
alert(typeof window.sessionStorage.removeItem);<br>
<br>
Safari shows 2 alerts, and the second one says 'function'.<br>
IE8 says "object doesn't support this property or method" if line 2 isn't commented out.  It returns type string when it is.<br>
Mozilla also won't run if line 2 is there, but it returns type object for line 3.<br>
<br>
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.<br>
<br>
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.<br>

<br>
Apologies if this is clear in the spec and I somehow missed it.  But, if not, I think a clarification might be necessary.<br>
</blockquote>
<br></div></div>
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.<br>

<br>
Regards,<br><font color="#888888">
Maciej<br>
<br>
</font></blockquote></div><br>