I agree. Our practice of releasing experimental features default disabled behinda command line flag is extremely valuable. We should make sure that this works well for new web APIs. It will continue to be a valuable tool down the road.
It is important that we have features available in stable, beta, and dev channels this way. Otherwise, what we ship to stable is not the same build configuration as what we ship to beta, and that can cause even more problems. -Darin On Mon, Sep 21, 2009 at 2:47 PM, Aaron Boodman <a...@chromium.org> wrote: > > It is really useful to have early code compiling and running as much > as possible on all platforms right from the beginning. This catches a > lot of issues early in the development cycle and prevents scary > monolithic integration phases. > > Could we also fix this problem by doing something in the > bindings-generation phase to just not have these features' > constructors created? > > - a > > On Mon, Sep 21, 2009 at 2:43 PM, Anthony LaForge <lafo...@google.com> > wrote: > > That raises an excellent point! I would extend those compile time flags > to > > include prevent experiments from getting into beta/stable as well. > > Kind Regards, > > > > Anthony Laforge > > Technical Program Manager > > Mountain View, CA > > > > > > 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. I'm working with Anthony > >> LaForge to fix this for LocalStorage/SessionStorage right now. I'm not > sure > >> if it's worth doing preemptively for other features, but it might be. I > >> definitely think we should do it the next time we cut a beta build. > >> Especially if there's a chance the beta will be an ancestor of a stable > >> channel release. > >> J > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
