Essentially we need to skip field trial setup in  ChromeBrowserMainParts::SetupMetricsAndFieldTrials. The tricky thing is that we land on the login screen first (i.e. to show the launch splash or manual kiosk), which is after SetupMetricsAndFieldTrials is called and might be difficult to undo the setup. One possible solution might be restarting Chrome before starting kiosk session.

We're going to try to get this into M-54 for 'stable' builds of kiosk only.

This raises an issue.  If it will only affect stable how do we test it in dev and beta....

The code for this is quite simple, but this requires rethinking and re-writing a lot of tests (enrollment tests don't expect Chrome to restart, hence the fake enrollment data is always in memory).

Hence punting to 55.

I'd prefer if we could avoid restarting Chrome in as much cases as possible (and avoid having black screen splash before launching kiosk app) - but that would require knowledge whether kiosk app session is likely to be launched very early on.
I could see this being possible in case of auto-launched kiosk sessions; e.g. we could introduce a local state property that gets set when app auto-launch is set, and not enable field trials whenever it's set.
Though, this approach would not work well for kiosk apps launched from login screen - I doubt we can avoid Chrome restart in that case.
Another problem would be the case where the user cancels app auto launch - would field trials have to be enabled in that case, as the user opted out of kiosk session.

I wonder if it would make sense to disable field trials based on whether the device has kiosk set to auto launched, rather than them disabled based on whether kiosk session is active or not. I'm not sure that this would cover all mission critical use cases targeted by this bug, though.

Simplicity is good. :-)

Disabling only if autolaunch is set is a good initial start.

Considering that the cases that this would really hit hard (Digital Signs, PoS systems, etc), this only working in auto-launch SGTM too. That is really the case we really want to optimize for, where just re-imaging is not exactly a very easy option.

If a user cancels auto-launch, it is such an epsilon that leaving finch disabled for that one session is not something we'd care about.


+2 to using local state to indicate to sessions started in auto-launch to disable.

Think it is reasonable to disable finch once an auto launch is configured.

We don't need a local state though because auto launch is part of device policy and the info is available on the login screen. KioskAppManager covers that. Usually auto launch refers to having an app to auto launch with 0ms delay on start.

We could use
  KioskAppManager* manager = KioskAppManager::Get();

  manager->IsAutoLaunchEnabled() &&  // auto launch is allowed
  !manager->GetAutoLaunchApp().empty() &&  // there is an auto launch app
  manager->GetAutoLaunchDelay() == base::TimeDelta()  // launch delay is 0ms

Yes, using KioskAppManager is an option I intended to look into, the main concern I have is whether it can be used as early as the time at which field trials are set up.

That is a valid concern. KioskAppManager depends on CrosSettings (for policy). It seems that CrosSettings is initialized before finch [1]. But I am not sure whether the policy values are fully loaded at that point. I suspect we get the cached policy blob from Local state but not sure.

[1] https://cs.chromium.org/chromium/src/chrome/browser/chrome_browser_main.cc?rcl=0&l=1194,1211

Experiments can only modify command-line flags. Why don't we just compare original command-line with current command-line and restart browser (using existing code) if need?

Or even simpler: if "enable-features" or "disable-features" exist, remove them from command-line and restart chrome with "disable-experiments" (new option).

(a) We don't know whether the enable/disable-feature flags are coming from Finch or from chrome_dev.conf or just the Chrome command line setup for a particular board.
(b) We really want to avoid restarting Chrome - we can, but only if it really gets us a big win.

The problem isn't as much with disabling finch as with recognizing that we're in Kiosk mode. If finch enables a flag that is processed in the Chrome startup code before our Kiosk mode check, we may have enabled/disabled that flag despite being in Kiosk mode.

We can store initial command-line somewhere to be able to compare it to the command-line after finch initialization.

I mean that having "we are in the kiosk mode" flag before enterprise policy is updated, users are initialized, etc is way more difficult and prone to future errors then to use existing mechanism of chrome restart when needed.

I don't think it should be that much of a problem to have a flag in CrosSettings that indicates whether field trials should be disable due to kiosk setup - it would be untrusted (and backed by local state) at the time when field trials are set up though. My plan to handle this was to attempt restart once the value becomes trusted and local state is updated with appropriate value (provided that trusted value differs from untrusted).
Well, I guess the same could be accomplished by bypassing CrosSettings, and keeping the new flag value in in Local State.

I would have less problem with just restarting Chrome once kiosk session is started if it was barely noticable to the user - but from my current observations it takes multiple seconds on link.

Let's discuss this more on Monday :)