Indeed. BTW I filed http://crbug.com/18577 so it'd be easier to find (and copy-paste) the command line flags used for a build. We can add this to the default template if it'd be useful. -Ben
On Mon, Sep 21, 2009 at 4:37 PM, Darin Fisher <da...@chromium.org> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
