New issue
Advanced search Search tips

Issue 830816 link

Starred by 1 user

Issue metadata

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



Sign in to add a comment

Racing for DBusThreadManager initialized in mash browser test

Project Member Reported by warx@chromium.org, Apr 9 2018

Issue description

I am currently working on a CL:https://chromium-review.googlesource.com/c/chromium/src/+/986889
to move PowerPrefs to ash, in that PowerPrefs's initialization depends on the initialization of chromeos::PowerPolicyController. chromeos::PowerPolicyController's initialization depends on chromeos::PowerManagerClient.

Before, those DBus clients are initialized by chrome (in chrome_browser_main_chromeos.cc) and only used by chrome before mustash.

Now I can see the plan for mash is to initialize DBus clients in window manager service for mash. In current mash browser test that requires injecting fake dbus clients, there could be problem.

(1) In browser test SetUpInProcessBrowserTestFixture(), DBusThreadManager initialized for testing could be done by chromeos::DBusThreadManager::GetSetterForTesting().
(2) Meanwhile, ash::WindowManagerService::OnStart() would enter here:
https://cs.chromium.org/chromium/src/ash/window_manager_service.cc?q=windowmanagerservice&dr=CSs&l=86, where it sees DBusThreadManager is not initialized (it sounds a racing to me) and initializes DBusThreadManager. Thus any injected fake dbus clients in browser tests are not injected. And any following ash code that depends on the dbus clients will not depend on the fake dbus clients in browser tests.
 
I suspect it is because WindowManagerService(ash) runs in a separate process in mash browser test rather than racing. The fakes might need to act somewhat like a real server to provide a consistent states to both ash and browser process.
Components: Internals>Services>Ash
Labels: -Proj-Mustash-Mash

Sign in to add a comment