On Mon, Sep 21, 2009 at 3:29 PM, John Abd-El-Malek <j...@chromium.org> wrote:
> > > On Mon, Sep 21, 2009 at 2:31 PM, Jeremy Orlow <jor...@chromium.org> wrote: > >> I think we need to re-consider our practice of shipping beta/stable >> browsers with experimental features hidden behind flags--at least when they >> have any side-effects in JavaScript. An example of where this has bitten us >> is http://code.google.com/p/chromium/issues/detail?id=22181 >> >> Although part of the problem is the way they coded things (since both >> SessionStorage and LocalStorage use the Storage interface, >> its existence doesn't imply SessionStorage is necessarily available), this >> bug has pointed out a couple problems. 1) constructors are visible to >> javascript even when the feature is totally disabled. 2) When an object >> (like the Storage interface) wraps a NULL it shows up as null in JavaScript. >> Since returning NULL/0 is the standard thing to do when the feature is >> disabled, this means that the functions return null when disabled at run >> time and undefined when disabled at compile time. 3) Even if we fixed the >> undefined problem, |'localStorage' in window| would still return true. >> >> We've been discussing these issues in a WebKit-dev thread ( >> https://lists.webkit.org/pipermail/webkit-dev/2009-September/thread.html#9860) >> and although (2) is probably something we can solve without too much effort >> (Drew is going to look into it), (1) and (3) probably aren't worth changing >> if the runtime flag is just temporary. >> >> *As such, I feel fairly strongly that we should start disabling features >> behing a run-time flag with compile-time flags in future beta/stable builds >> if they have any side-effects in JavaScript.* >> > > Having features enabled behind command line flag has been very helpful in > tracking down bugs and getting the wider population to test something. It's > also useful when debugging on someone's machine. > Which features/flags (with side effects in JavaScript) have you found helpful when debugging *stable/beta* versions? Which of those were helpful in stable versions? It sounds like the problem is how we're keying off the run time flag (i.e. > not in the bindings). > No, the problem is the bindings. We'd need to add more logic to them to handle these cases. > When I looked at the database bindings, there was no way to both use the > automatically generated constructor and not have side effects. > Exactly. And so the alternative is to add custom bindings or to change the code generator. Both have a price in terms of development, performance, and maintenance. As I said, I believe Drew is going to explore this when he enables shared workers behind a flag. > I think it's worth the tradeoff to make it custom in the meantime. > Please reply to https://lists.webkit.org/pipermail/webkit-dev/2009-September/009995.htmlthen. Whether or not we make these run time flags have no side-effects in the future, there's still the matter of what we should do for Chrome 3 since adding in custom getters and such seems like a very high risk for little reward. J --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
