[webkit-dev] Runtime setting for incomplete features

[Jeremy Orlow]

On Mon, Oct 5, 2009 at 6:40 PM, Sam Weinig <sam.weinig at gmail.com> wrote:

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

If there are any features in the Safari WebKit nightlies that are enabled at
compile time but disabled at run time, this is likely unintentional and is
what should be fixed.  More on this below....


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

They were originally added in this patch:
http://trac.webkit.org/changeset/38234  Note that that patch exposes them
through the windows and mac WebKit APIs, so I'm not sure you can really call
it "not a shipping configuration" unless you're only talking about Safari.

So here's the problem:  These run time flags have all been modeled on the
localStorage and database runtime flags.  The problem with these flags is
that you have to opt-in at compile time _and_ at run time.  This probably
makes sense for features that can have lasting side effects like
localStorage and Database, but for features like WebSockets, Notifications,
and SharedWorkers, its probably the wrong behavior.

So maybe we should change the defaults in Settings to true for all of these?
 After all, if a feature is compiled out, then the setting will be ignored.
 And if it's compiled in, the port probably wanted it enabled anyway.  It
might actually be better to simply not compile in the Setting when the
compile time flags are disabled, but that'd involve more #ifdef's.

J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091005/7d9cc622/attachment-0001.html>