[webkit-dev] Runtime setting for incomplete features

[Sam Weinig]

On Mon, Oct 5, 2009 at 6:33 PM, Drew Wilson <atwilson at google.com> wrote:

>
> On Mon, Oct 5, 2009 at 6:20 PM, Sam Weinig <sam.weinig at gmail.com> wrote:
>
>>
>>
>> On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson <atwilson at google.com> wrote:
>>
>> I'm surprised to see these objections coming up now, weeks after the
>>> original discussion, and only after my patch has landed in the tree.
>>>
>>
>> Sorry, I seemed to have missed that thread. I did however file a bug as
>> soon as the first runtime switch went in.
>>
>>
>>> That said, I agree that in an ideal world, we'd hide window.audio, shared
>>> workers, notifications, local storage, databases, session storage and any
>>> other runtime/platform-disabled API from enumerations - I just agree with
>>> Maciej that this isn't a hugely important issue, since these features are
>>> only runtime-disabled while under development and so not widely available
>>> anyway.
>>>
>>
>> I obviously disagree with Maciej on this. I think it is bad to break
>> developers expectations for feature detection.
>>
>>
> OK, it's good to get consensus, even if it comes after I already thought we
> had achieved it :)
>
> From a purist's perspective, I see where you're coming from. Pragmatically,
> though, these runtime flags are only available on the Chrome dev channel
> (and go away before the features are ever shipped to the beta/stable
> channels) so the compatibility issues are somewhat moot. We've discussed
> removing these feature flags (and the ability to disable the features at
> runtime) once the features become stable - I don't know if that's a good
> idea or not, but that might impact this discussion as well.
>

That is not true, they are also available in nightly builds at
http://nightly.webkit.org/.


>
>
>>
>>> Regardless, I don't think we should rush out to roll all of those
>>> features out of the tree, and I certainly don't think we should be singling
>>> out SharedWorkers or WebSockets
>>>
>>
>> I don't mean to single out SharedWorkers or WebSockets, but I don't see
>> any others using the same technique (barring window.Audio, which I don't
>> think is the same thing, but should non-the less be fixed).  But, as we have
>> many developers using the nightlies, I think this should be handled with
>> some speed.
>>
>
> Take a look at DOMWindow.cpp - there's quite a bit of code that does
> something like "look at settings to see if feature is enabled, return null
> if not" (DOMWindow::openDatabase(), for an example).
>
>
This is indeed unfortunate, but also is a step removed, since it does not
really effect feature detection, it is also not a shipping configuration.

-Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091005/ed0df09e/attachment.html>