[webkit-dev] Runtime setting for incomplete features

[Maciej Stachowiak]

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.

>
> 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).

Regards,
Maciej

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