[webkit-dev] Runtime setting for incomplete features

[Michael Nordman]

window.applicationCache does something different when the runtime switch is
disabled which definitely breaks feature detection. It returns a non-null,
but non-functioning object. At some point I had changed it to return 'null'
when disabled, but  later reverted that change and went back to the non-null
but not-working state of affairs after discussing things with ap.
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.
>>
>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>> 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?
>>
>>
>>>
>>> -Sam
>>>
>>
>>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091005/11767a0f/attachment.html>