New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 766158 link

Starred by 5 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

about:flags doesn't work for ChromeOS-on-Linux

Project Member Reported by treib@chromium.org, Sep 18 2017

Issue description

What steps will reproduce the problem?
(1) On Linux, set target_os="chromeos" in GN, build chrome and run, see the "virtual ChromeOS".
(2) Go to about:flags, flip some flags.
(3) Hit the "Restart now" button (which just closes Chrome, so start it again).

What is the expected result?
Flags take effect.

What happens instead?
No effect (though the flags do show up as "Enabled" on about:flags).


I tried a few flags of SINGLE_VALUE_TYPE, SINGLE_DISABLE_VALUE_TYPE, and FEATURE_VALUE_TYPE, none have any effect. (I've verified manually that CommandLine::HasSwitch or FeatureList::IsEnabled return false.)

Instead of hitting "restart now" button, I've also tried chrome://restart as well as manually closing and restarting Chrome.

Enabling features via the command line (--enable-features=...) works fine.
 

Comment 1 by derat@chromium.org, Sep 19 2017

Cc: derat@chromium.org mnissler@chromium.org
I'm not super-familiar with how this is supposed to work, but I think that flags are typically passed from Chrome to session_manager and used there to construct Chrome's command line. I'm not sure how much work it'd be to make this work[1] when an OS_CHROMEOS build is run on a desktop machine.

1. presumably in the same way that desktop Chrome applies flags, which I'm not at all familiar with

Comment 2 by msw@chromium.org, Sep 19 2017

Cc: alemate@chromium.org xiy...@chromium.org achuith@chromium.org
I'm hitting this as well, it repros regardless of using --login-manager or not.
(checking CommandLine::ForCurrentProcess() in OnSessionStateChanged)
This is a bummer and makes development/experimenting a bit harder.

I'm not sure if this is a recent regression or a long-standing defect.
Cc'ing components/session_manager/OWNERS for thoughts/triage.

Comment 3 by est...@chromium.org, Jan 23 2018

I am, weirdly, having the opposite problem. My chrome://flags flag doesn't work on any ChromeOS device, but it does work when I build chromeos locally and run on linux. I'm pretty sure this is a problem with chrome://flags because the corresponding Finch trial works fine. (issue 804826)

Has anyone looked into this bug? Not sure if my problem is related but I'm curious.

Comment 4 by xiy...@chromium.org, Jan 23 2018

As Dan mentioned in #1, the way user flags works for chromeos depends on session manager daemon.

The user flags is per-user and stored in the user profile. This is not available at the login screen (only sign-in profile is loaded at that time). After user signs in, chrome loads the user profile and see the user flags. It will then construct the new command line, send to session manager daemon and asks for a chrome restart. Session manager would restart chrome with the new command line. [1]

On dev box, SessionManagerClientStubImpl is used since there is no sessino manager daemon. And the stub does not implement SetFlagsForUser and chrome::AttempRestart just exits. It should not be hard to implement as we already did something to simulate guest login on dev box. 

How bad do we need this to be supported? As a developer, one could always support relevant command line switches when starting chrome to test the feature, right?

[1]: https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/session/user_session_manager.cc?rcl=e70e2872be3a7cbee94d3547f33071f6c8ba20df&l=831-835

Comment 5 by xiy...@chromium.org, Jan 23 2018

Re #3, I responded to issue 804826 about one possibility that flags not working on device.

Sign in to add a comment