[webkit-dev] Runtime setting for incomplete features
sam.weinig at gmail.com
Mon Oct 5 17:04:12 PDT 2009
I am not happy with the way these runtime settings have been implemented so
far as they break runtime detection using the technique we evangelize to
developers, specifically, using the ("property" in window) method. A
feature that is turned off at runtime should not be detectable at all, using
any method (including Object.keys(), object.hasOwnProperty(),
object.propertyIsEnumerable(), for-in enumeration, etc). I filed
https://bugs.webkit.org/show_bug.cgi?id=29896 when the WebSocket runtime
switching code went in and was disappointed to see similarly buggy code go
in for SharedWorkers with out this being fixed.
Leaving this in the tree is likely to introduce compatibility issues so I
would recommend that we roll out these changes if they cannot be fixed in a
On Tue, Sep 8, 2009 at 11:47 PM, Darin Fisher <darin at chromium.org> wrote:
> As is described in https://bugs.webkit.org/show_bug.cgi?id=28941, for
> the Chromium project, we like to make incomplete features available
> behind a command line flag to help facilitate testing. I understand
> that the norm for WebKit is to only have compile time options for new
> / incomplete features. In some cases, runtime settings are defined,
> but these generally correspond to end user preferences or the needs of
> specific embedders.
> At any rate, I just wanted to make sure that folks were aware that
> some settings may only exist to help facilitate Chromium's goal of
> shipping incomplete features, disabled by default.
> Alexey asked if there are any guidelines for when these settings may
> be removed. I think the main thing is that the feature has to be
> reasonably complete and enabled by default by embedders (e.g.,
> Chromium) that are compiling the feature.
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev