IMPORTANT Clarification about about:labs

[Ben Goodger (Google)]

Since its introduction, I run into confusion about about:labs at least a few times a week. Let me make it absolutely clear by using bolded, enlarged text:

There should be no judgment call you make about whether or not you add your experimental toggle to about:labs. The answer is always YES ADD IT to about:labs.

about:labs is meant as a UI to command line flags.

Using a command line flag to enable an experimental feature or mode is now deprecated in favor of about:labs.

If your configuration option requires a parameter and you're the first person to edit about:labs, you're going to have to adjust the framework to support a configuration parameter. It'd be great if someone added a command line to toggle labs features also. But the labs list should be the canonical configuration.

When I start work on a new feature, I add a switch to enable it early on, often before much of the feature is even implemented. You should apply this methodology to about:labs switches too. We have a scary warning there explaining the consequences.

Once more, for the road: ADD YOUR FEATURES AND EXPERIMENTS TO ABOUT:LABS EARLY AND OFTEN.

As a side note, we are going to rename about:labs to make it sound less friendly.

-Ben

(The only sort of thing that doesn't really belong in about:labs are things useful only for debugging like --single-process etc). 

[Evan Martin]

On Tue, Oct 12, 2010 at 8:20 AM, Ben Goodger (Google) <b...@chromium.org> wrote:
> There should be no judgment call you make about whether or not you add your
> experimental toggle to about:labs. The answer is always YES ADD IT to
> about:labs.

What are your thoughts on half-baked features making it out to stable channels?

I worry that we'll manage to snapshot a feature with known bugs onto a
stable channel; should we be backporting fixes? (How about before we
release but when we have a release branch?) Or should we just
acknowledge that stuff in about:labs on stable will usually be broken?

(I have no opinion on this, sorry if my questions seemed leading.)

[Ben Goodger (Google)]

We are already shipping half-baked features to stable, but the interface is --enable-half-baked-feature.

Remember: The first rule of about:labs is about:labs is a simpler GUI for command line flags. It's necessary because command line flags are such a PITA that developers on the team aren't eating important dogfood (e.g. Instant). When there's a GUI, it's much easier to get people on the team to change their configuration.

chrome-ui-leads has decided that having a page that is hidden with no entrypoints from Chrome UI and a scary warning on the page is sufficient to disclaim our responsibility to those that turn these things on.

-Ben

[Mike Belshe]

On Tue, Oct 12, 2010 at 8:33 AM, Ben Goodger (Google) <b...@chromium.org> wrote:

We are already shipping half-baked features to stable, but the interface is --enable-half-baked-feature.

That isn't the same thing though - a command line is far more obscure than about:labs, where anyone curious about what appears to be a chrome "easter egg", can find it.  So with about:labs, an errant blog post could trigger a bunch of accidental users in a way that the command line never will.  Also, the about:labs UI wouldn't scale to the number of command line options that we currently have, would it?  If we really believed that about labs was a way to do command line switches, then we'd change chrome_switches.cc to provide a struct which automagically populates the UI in about:labs...

There must be a razor for when you'd want a lab and when you would not.  My thought is that labs are really only useful for UI related features?  Err - that's not even quite right.

Mike

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Ben Goodger (Google)]

In my original email I suggested providing a 1:1 mapping between labs and command line switches :-)

We looked at this and decided the impact was similar enough to using a dev channel that we didn't care. Yes if you're going to read a tech blog and go into a secret page that you can only get to by typing in the omnibox and enable a feature and restart despite the scary warning, you may get something unpredictable.

-Ben

[Paweł Hajdan, Jr.]

Is there some info how to add things to about:labs? Adding a new command-line switch is very well known, but about:labs is a new thing.

--

[Andrew Bonventre]

Should we be using about:labs as a replacement of command line flags?

[Vincent Scheib]

The GUI, and stateful memory of options in the profile, are nice. An issue recently brought up:

Transitioning to a "default off" to "default on" for a feature won't be preserved by the preferences. e.g. --enable-webgl changed to --disable-webgl. We're going to have to toggle it back and forth again for M8 and M9 as well! Command line flags don't go bad - so developers who've left "--enable-webgl" in their command-line don't have to worry about us fiddling that switch around.  -- fix: add a way for labs to be "defaulted on"? I didn't implement this as at the time arguments were that :labs were more restrictive and that this was too complicated.

[Nico Weber]

On Tue, Oct 12, 2010 at 8:49 AM, Paweł Hajdan, Jr.
<phajd...@chromium.org> wrote:
> Is there some info how to add things to about:labs? Adding a new
> command-line switch is very well known, but about:labs is a new thing.

It's super-easy: Labs is really just a UI for command-line flags atm,
so you add a command-line parameter as before and then add 4 lines of
code (lab name, lab description, supported OSs, command line param it
maps to) to chrome/browser/labs.cc .

Nico

[Rohit Rao]

Is there a rule for where to add new labs? Alphabetical? At the
bottom? Wherever you want? Do we even care?

- Rohit

[Ben Goodger (Google)]

I don't care. :-)

-Ben

[Ben Goodger (Google)]

We received a directive from the supreme leader that we should make experiments available to all channels.

We could possibly allow this to be configured this per-experiment provided they always at least show up on dev.

I am going to file a bug with the feature and cleanup requests that have stemmed from this thread.

-Ben

On Tue, Oct 12, 2010 at 10:14 AM, Aaron Boodman <a...@chromium.org> wrote:

On Tue, Oct 12, 2010 at 8:20 AM, Ben Goodger (Google) <b...@chromium.org> wrote:
> Since its introduction, I run into confusion about about:labs at least a few
> times a week. Let me make it absolutely clear by using bolded, enlarged
> text:
> There should be no judgment call you make about whether or not you add your
> experimental toggle to about:labs. The answer is always YES ADD IT to
> about:labs.
> about:labs is meant as a UI to command line flags.
> Using a command line flag to enable an experimental feature or mode is now
> deprecated in favor of about:labs.
> If your configuration option requires a parameter and you're the first
> person to edit about:labs, you're going to have to adjust the framework to
> support a configuration parameter. It'd be great if someone added a command
> line to toggle labs features also. But the labs list should be the canonical
> configuration.
> When I start work on a new feature, I add a switch to enable it early on,
> often before much of the feature is even implemented. You should apply this
> methodology to about:labs switches too. We have a scary warning there
> explaining the consequences.
> Once more, for the road: ADD YOUR FEATURES AND EXPERIMENTS TO ABOUT:LABS
> EARLY AND OFTEN.
> As a side note, we are going to rename about:labs to make it sound less
> friendly.

Is there a way to specify in the configuration that an experiment
should only be accessible on dev? That would address the concern that
has been brought up (several times, and ignored) that this makes it
much easier for stable users to get themselves into trouble.

- a

[Aaron Boodman]

On Tue, Oct 12, 2010 at 8:20 AM, Ben Goodger (Google) <b...@chromium.org> wrote:

> Since its introduction, I run into confusion about about:labs at least a few
> times a week. Let me make it absolutely clear by using bolded, enlarged
> text:
> There should be no judgment call you make about whether or not you add your
> experimental toggle to about:labs. The answer is always YES ADD IT to
> about:labs.
> about:labs is meant as a UI to command line flags.
> Using a command line flag to enable an experimental feature or mode is now
> deprecated in favor of about:labs.
> If your configuration option requires a parameter and you're the first
> person to edit about:labs, you're going to have to adjust the framework to
> support a configuration parameter. It'd be great if someone added a command
> line to toggle labs features also. But the labs list should be the canonical
> configuration.
> When I start work on a new feature, I add a switch to enable it early on,
> often before much of the feature is even implemented. You should apply this
> methodology to about:labs switches too. We have a scary warning there
> explaining the consequences.
> Once more, for the road: ADD YOUR FEATURES AND EXPERIMENTS TO ABOUT:LABS
> EARLY AND OFTEN.
> As a side note, we are going to rename about:labs to make it sound less
> friendly.

Is there a way to specify in the configuration that an experiment

[Daniel Kurtz]

Sorry if this is already answered somewhere else, but...

If I enable a feature with about:labs, and the feature crashes the browser on startup - before I can even navigate to "about:labs" - how can I turn it back off?

Are the currently enabled lab features also stored in a human readable file somewhere?

With a command-line flag, its easy, just re-run without the flag.

-Dan

[Nico Weber]

On Tue, Oct 12, 2010 at 10:42 AM, Daniel Kurtz <djk...@google.com> wrote:
> Sorry if this is already answered somewhere else, but...
> If I enable a feature with about:labs, and the feature crashes the browser
> on startup - before I can even navigate to "about:labs" - how can I turn it
> back off?
> Are the currently enabled lab features also stored in a human readable file
> somewhere?

In short, don't add switches that crash the browser on startup :-)

It's stored in the profile file. Search $PROFILE_DIR/Default/Profile
for "enabled_labs_experiments" and delete that line.

If that ever happens in practice, we could add a --disable-labs flag.

[Stuart Morgan]

On Tue, Oct 12, 2010 at 11:13 AM, Nico Weber <tha...@chromium.org> wrote:
> In short, don't add switches that crash the browser on startup :-)

I know you were kidding, but even so it downplays the serious concern
here. "Don't add a wildly broken lab" sounds easy, but what "never
make any change that interacts badly with any combination of labs,
despite the fact that none of our automated testing will be testing
that large combinatorial space at all" is not so easy even in theory.

We should be planning in terms of *when* this happens, not if.

-Stuart

[Paweł Hajdan, Jr.]

On Tue, Oct 12, 2010 at 20:13, Nico Weber <tha...@chromium.org> wrote:

If that ever happens in practice, we could add a --disable-labs flag.

Ouch, we haven't already? 

[Evan Stade]

On Tue, Oct 12, 2010 at 8:48 AM, Ben Goodger (Google) <b...@chromium.org> wrote:
> In my original email I suggested providing a 1:1 mapping between labs and
> command line switches :-)

isn't there already a 1:1 mapping between labs and command line
switches?* Every lab relies on a command line switch. Meaning that the
directive "Using a command line flag to enable an experimental feature
or mode is now deprecated in favor of about:labs." doesn't quite make
sense to me.

*actually an injection rather than a a bijection

[Nico Weber]

No. Originally this was intended for somewhat stable things, not for every flag.

[David Levin]

Running with --single-process puts up a nice infobar when you start Chrome warning you that you are running with an unsupported option.

Should we do this for any lab that is turned on?

   You have some labs (about:labs [link]) turned on. This may affect the stability of your browser.

dave

--

[John Abd-El-Malek]

This is actually a really annoying infobar, especially since we ignore --single-process for released builds.  So it only annoys developers, who know what they're doing.

[David Levin]

On Wed, Oct 13, 2010 at 9:59 AM, John Abd-El-Malek <j...@chromium.org> wrote:

This is actually a really annoying infobar, especially since we ignore --single-process for released builds.  So it only annoys developers, who know what they're doing.

 

Got it. You don't like the infobar for the single process flag. (Feel free to start a thread about removing it.)

about:labs will be available in release builds, and an infobar would make it very noticeable that labs are set.

It is not unthinkable and in fact probable that a number of outlets will note the ui and tell people to change things in it. Then they will forget that they set the options and get broken (or perhaps insecure) behavior. The infobar seems like a nice solution for this.

dave

[Evan Martin]

I'd be ok with both of:
1) removing the infobar for non-official builds
2) restoring --single-process for official builds since we have the
infobar for protection

(It's frequently useful to be able to ask a user to run with
--single-process for diagnosing crashes.)

[Peter Kasting]

On Tue, Oct 12, 2010 at 4:08 PM, David Levin <le...@google.com> wrote:

It is not unthinkable and in fact probable that a number of outlets will note the ui and tell people to change things in it. Then they will forget that they set the options and get broken (or perhaps insecure) behavior.

The correct solution to this (as discussed at the UI meeting and possibly other places) is that your feature should "get the heck out" of labs the instant it's not in a state where a command-line switch is the right thing for it.  Someone suggested the rule of thumb "after something has been in labs for two releases it needs to either be removed from the product or turned on/moved to prefs/whatever".  This dovetails well with previous admonishments on this list about having too many switches, and the need to not have them persist forever.

PK

[David Levin]

Sometimes it takes a while to develop features.

If a flag is put in shortly before a release, then you have basically 1 release of time (which is pretty short now) before you hit the two release critera.

 

PK

[Scott Hess]

I don't think about:labs should be used to prototype features. If
it's in there for more than two releases, you probably shouldn't have
put it in, yet. If about:labs becomes the way that we stuff the
release cycle, I will be sad.

-scott

[David Levin]

On Wed, Oct 13, 2010 at 11:16 AM, Scott Hess <sh...@chromium.org> wrote:

On Tue, Oct 12, 2010 at 5:11 PM, David Levin <le...@google.com> wrote:
> On Wed, Oct 13, 2010 at 11:04 AM, Peter Kasting <pkas...@chromium.org> wrote:
>> On Tue, Oct 12, 2010 at 4:08 PM, David Levin <le...@google.com> wrote:
>>> It is not unthinkable and in fact probable that a number of outlets will
>>> note the ui and tell people to change things in it. Then they will forget
>>> that they set the options and get broken (or perhaps insecure) behavior.
>>
>> The correct solution to this (as discussed at the UI meeting and possibly
>> other places) is that your feature should "get the heck out" of labs the
>> instant it's not in a state where a command-line switch is the right thing
>> for it.  Someone suggested the rule of thumb "after something has been in
>> labs for two releases it needs to either be removed from the product or
>> turned on/moved to prefs/whatever".  This dovetails well with previous
>> admonishments on this list about having too many switches, and the need to
>> not have them persist forever.
>
> Sometimes it takes a while to develop features.
> If a flag is put in shortly before a release, then you have basically 1
> release of time (which is pretty short now) before you hit the two release
> critera.

I don't think about:labs should be used to prototype features.

Pls see the original email:

Using a command line flag to enable an experimental feature or mode is now deprecated in favor of about:labs.

 

Adding a command line flag for something under development has been my first step of development on it, so I have the guard for it in various places as I develop it.

dave

[Peter Kasting]

You'll note I said "rule of thumb".  I think the rule applies pretty well in most cases.  It's fairly rare that we need more than six weeks of "checked in, behind a flag" time to get a feature to the "not done, but limping along in Dev channel" state.  If we truly need it for something, we need it.  Just want to push people not to think it's OK to leave something in labs because e.g. "we're not going to turn it on by default but a lot of people like it so I don't want to take it out", or similar.

PK

[Nico Weber]

I don't think we'd throw out stuff that's under active development and
on a clear way forward. What Peter meant was more that nothing should
stay in there for indefinite time. Stuff either improves and
ultimately ends up in stable as a non-lab, or is removed again.

Nico

> dave
>
>>  If
>> it's in there for more than two releases, you probably shouldn't have
>> put it in, yet.  If about:labs becomes the way that we stuff the
>> release cycle, I will be sad.
>
>
>>
>> -scott
>

[Jonathan Dixon]

On 12 October 2010 19:02, Nico Weber <tha...@chromium.org> wrote:

It's super-easy: Labs is really just a UI for command-line flags atm,

so you add a command-line parameter as before and then add 4 lines of
code (lab name, lab description, supported OSs, command line param it
maps to) to chrome/browser/labs.cc .

One questions that occurred to me when I was looking at the labs.cc file - is there a common way already in place for gathering metrics on which labs are in use and so forth? In other products, Labs are useful for gauging user interest in a feature, seems consistent to add support for that here without requiring each lab to have to enable its own usage logging. (e.g. How many users have any lab enabled? / how many users have my lab enabled? / how many users enabled then removed my lab? / etc)

[Nico Weber]

At the moment, there isn't. My thinking was that you want to add UMA
stuff to your feature itself anyway, so that you get usage data when
it's out of labs, too. But adding counters for "any lab enabled?" and
"for all X: lab name X enabled" sounds like a good idea. Patches
welcome :-)

Nico