[webkit-dev] Runtime setting for incomplete features
jorlow at chromium.org
Mon Sep 21 13:33:46 PDT 2009
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
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.
today. And, if not, then we should probably differ such a discussion until
> 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev