On Mon, Sep 21, 2009 at 12:17 PM, Maciej Stachowiak <[email protected]> wrote:
> > On Sep 18, 2009, at 1:30 PM, Jeremy Orlow wrote: > > On Fri, Sep 18, 2009 at 12:59 PM, Alexey Proskuryakov <[email protected]>wrote: > >> >> 18.09.2009, в 12:24, Jeremy Orlow написал(а): >> >> I'm not sure if we've hit any compatibility issues with this yet, but it >>> seems quite plausible that someone would compare window.localStorage (or >>> sessionStorage or database) to undefined and, since it's null (vs. >>> undefined), their script would assume it's available. >>> >> >> Note that they can also do '"localStorage" in window', which we can't >> easily prevent from returning true. >> > > That's true. And unfortunate. > > What would be involved in making it not return true? > > > It would be pretty complicated to do that based on a runtime setting. You > would need a custom getter for any object that has properties which may > appear or disappear based on settings. > Some of these already have a custom getter. Maybe it makes sense to go ahead and do it for them? > This is probably too complicated to be worth it. Or at least, if we added > that level of code complexity I would begin to doubt the merits of > supporting runtime enabling of Web platform features. > I think it depends on why it's enabled at run time. If it's a feature that some users might want to completely turn off, then I think there's some merit to going the extra mile to disable it in run time. But if it's something that's disabled because it's experimental, then I'd lean towards your point of view. > Which is a shame, because if ("localStorage" in window) is a generally a > better way to feature test than if (window.localStorage). The latter idiom > is problematic for attributes where a possible valid value is something that > evaluates to false, or where computing the value can be expensive. For > example, if (document.body.outerHTML) would be an awful way to test whether > outerHTML is available. > Agreed. In practice, I can't think of anything we'd disable in run time like that, but it's obviously more difficult for the web developer to know this. Even if we can't make the property not show up, would you agree that returning undefined is better than returning null?
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
