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

Reply via email to