[webkit-dev] Runtime setting for incomplete features

[Jeremy Orlow]

With databases, localStorage, and sessionStorage, there is a Settings option
for enabling or disabling the feature.  If it's disabled,
DOMWindow::localStorage returns 0 (i.e. null) which is then wrapped in an
object of type Storage by the bindings.  This results in |alert((typeof
window.localStorage) + " " + window.localStorage);| showing "object null"
when ENABLE(DOM_STORAGE) but settings()->localStorageEnabled() is false.
 When DOM_STORAGE is not enabled, it returns undefined.
I'm not sure if we've hit any compatibility issues with this yet, but it
seems quite plausible that someone would compare window.localStorage (or
sessionStorage or database) to undefined and, since it's null (vs.
undefined), their script would assume it's available.

So the question is this: should we be setting custom functions for
window.localStorage and friends that turn nulls into undefines in both
bindings (eww), just the v8 bindings (double eww), or should we change the
code generators to do this for us.  Or does the current behavior (apps being
able to distinguish between something disabled at run time vs. compile time)
make sense?

Also, is there anyone besides Chromium compiling in DOM_STORAGE but
disabling localStorage via Settings?

J

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.
>
> Regards,
> -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/20090918/4f7b5ec1/attachment.html>