[webkit-dev] Runtime setting for incomplete features

[Jeremy Orlow]

On Mon, Sep 21, 2009 at 12:17 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Sep 18, 2009, at 1:30 PM, Jeremy Orlow wrote:
>
> On Fri, Sep 18, 2009 at 12:59 PM, Alexey Proskuryakov <ap at webkit.org>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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090921/f4746440/attachment.html>