On Mon, Sep 21, 2009 at 3:43 PM, Jeremy Orlow <jor...@chromium.org> wrote:
> 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? > Things like dev tools, OOP, new safe browsing, different memory models and allocators, no activex, disabling plugins/javascript are what comes to my mind. Not just for debugging, but also for using them, and for having users with problems try them out to see if it fixes them. As Chrome is maturing as a browser, feature development will move from infrastructure to web features, which is why the list is biased to the former, but the same benefits still exist. There is also cost of maintaining different dev/beta/stable and Chrome/Chromium releases, in terms of testing, release processes, user confusion etc. > 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. > oops, I meant "in the bindings", hence my statement below :) > > >> 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. > What's wrong with this thread? We're discussing what to do in Chrome. > > > 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. > Really? Why is it very high risk? > > J > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
