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 -~----------~----~----~----~------~----~------~--~---
