[webkit-dev] Runtime setting for incomplete features

[Jeremy Orlow]

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

>
> On Sep 21, 2009, at 12:31 PM, Jeremy Orlow wrote:
>
> 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.
>
>
> Fair enough. But I would be against user-level preferences that add or
> remove entire APIs. Rather, the preference should affect the behavior of the
> API (possibly making it do nothing). So far the only actual user-level
> preference I'm aware of that effectively disables APIs is private browsing.
> And I think the way it works (in both Safari and Chrome, even though it is
> different) is better than it would be to make storage-related APIs disappear
> completely.
>

Agreed.  I would think something like "disable Java" (not the best example,
but I think it makes the point) should have obvious side effects though.
 That said, I can't think of any JavaScript APIs where it does make sense
today.  And, if not, then we should probably differ such a discussion until
there is.

> 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 though this style of feature test is better, it's tragically much less
> common than if (window.fooBar), so it's likely not a problem in practice.
>
>
> Even if we can't make the property not show up, would you agree that
> returning undefined is better than returning null?
>
>
> Slightly better. The only real difference it would make is if someone tests
> using a === comparison to undefined (as opposed to == or just a plain
> boolean test).
>

Given that this really only applies to "experimental" features, I don't
think we should spend too much effort on this.  But Drew, I do think it'd be
valuable if you played around with it.  And if any of this isn't too
hard/messy to do, I think it would be somewhat valuable.

I'm also going to send mail to chromium-dev proposing that we never ship
anything but a "dev channel" browser with such experimental features
compiled in for the reasons we've discussed here.

J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090921/51cbfd3e/attachment.html>