[webkit-dev] Runtime setting for incomplete features

[Sam Weinig]

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

> Ooops, meant to reply to all.
>
>
> On Mon, Oct 5, 2009 at 7:49 PM, Drew Wilson <atwilson at google.com> wrote:
>
>>
>>
>> On Mon, Oct 5, 2009 at 6:40 PM, Sam Weinig <sam.weinig at gmail.com> wrote:
>>
>>>
>>>
>>> That is not true, they are also available in nightly builds at
>>> http://nightly.webkit.org/.
>>>
>>
>> I'm not sure what you mean, exactly - the nightly webkit builds all have
>> SharedWorkers turned on, with no way to turn them off short of editing the
>> source code and recompiling (since the only existing implementation of
>> SharedWorkerRepository.isAvailable() returns true). I suspect I'm missing
>> something obvious, though - can you elaborate?
>>
>> My expectation was that only when I write the Chromium implementation of
>> SharedWorkerRepository will isAvailable() ever return false - so this only
>> affects Chromium deployments.
>>
>
Ok, but this is not the case for WebSockets.


>
>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>> 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.
>>>
>>
>> Why doesn't it affect feature detection? Someone can do "if localStorage
>> in window", yet have their code fail when window.localStorage is null?
>>
>
I only looked at window.openDatabase(), since that is what you called out.
 Again, this is unfortunate and should be rectified, but it does not
represent a real concern in my mind, since I don't know of any shipping
webkit based browsers that ship with this configuration on or an accessible
preference to get this way.

The good news is that it looks like we can fix this for nightlies by
enabling the WebSocket runtime switch.

I would still very much like a good solution to runtime enabling/disabling
features in the bindings as I think this would be a useful addition to the
webkit arsenal and I am curious why it is thought that doing it right will
be prohibitively expensive (it may very well be, I just don't know why that
is).

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