[webkit-dev] Runtime setting for incomplete features

[Drew Wilson]

Circling back on this - I have a patch together for the V8 side of this
issue (code generation changes and associated infrastructure). I'm just
waiting for someone to R+ it for me:
https://bugs.webkit.org/show_bug.cgi?id=30240 -- if someone can take a look
at this, I can get this in the tree, and we can start working on the second
half of the fix:
Currently many of these runtime enabled flags are sitting in
WebCore::Settings. This is a fairly inappropriate place for them, for a few
reasons -

1) We need to have access to these Settings *before* the window object is
initialized (as part of initializing the V8 bindings), and this is
difficult/impossible the way the bindings are currently generated.
2) The Settings objects aren't available from worker context, so some
runtime features (like notifications) can't be disabled from worker context.

So the second half of this fix is to move things like
"experimentalWebSocketEnabled" out of WebCore::Settings and into some other
kind of static object that's threadsafe and universally accessible. I'm not
certain if this needs to be part of WebCore proper, or if all we care about
is disabling V8 bindings, this is a static singleton class that can live in
the V8 bindings themselves.

Anyhow, I don't have strong opinions about the right way to go here, but I
*would* like to get my codegen changes checked in so I can unblock
SharedWorkers :)

-atw

On Mon, Oct 5, 2009 at 10:00 PM, Darin Fisher <darin at chromium.org> wrote:

> On Mon, Oct 5, 2009 at 9:56 PM, Jeremy Orlow <jorlow at chromium.org> wrote:
>
>> On Mon, Oct 5, 2009 at 9:54 PM, Mark Rowe <mrowe at apple.com> wrote:
>>
>>>
>>> On 2009-10-05, at 21:48, Darin Fisher wrote:
>>>
>>>  It is a matter of our process that we do not change the configuration
>>>> when promoting builds.  The bits that passed the test get promoted.
>>>>
>>>> I'm happy to absorb this cost in the V8 bindings.  I don't think it is
>>>> important to solve this problem for the JSC bindings since there is not a
>>>> consumer that yet needs the same.
>>>>
>>>
>>> The present state of Web Sockets is that they're compiled in on Mac OS X
>>> but disabled via the runtime setting.  This leads to them being detectable
>>> in the manner Sam mentioned.  Either the compile-time setting needs to be
>>> fixed for Mac OS X or the runtime code fixed so that the feature is not
>>> detectable when disabled.  I assume that we want regression testing of the
>>> feature so disabling it at compile time does not seem like the best idea.  I
>>> guess it comes down to whether or not it's in good enough shape to be useful
>>> to web sites at this time.
>>>
>>
>> I don't believe that anyone is shipping a working implementation of
>> WebSockets yet (or is Firefox's working now?), in which case it shouldn't
>> matter to have it on by default.
>>
>
> It matters for feature detection in the future.  Once there are real
> implementations in the wild, those will be detected in the same way that the
> current implementation is detected.  If the implementations aren't
> compatible (because one is very incomplete), then it makes the detection
> less reliable, and one must then resort to UA sniffing hacks.
>
> -Darin
>
> _______________________________________________
> 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/20091011/32ff126c/attachment.html>