The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7e440443c0dd5d86061c4084e0964605c8724c2b

commit 7e440443c0dd5d86061c4084e0964605c8724c2b
Author: Mike Wasserman <msw@chromium.org>
Date: Mon Oct 16 16:59:11 2017

ash: Make local shelf pref init more reliable on first sign-in.

Nix ChromeLauncherPrefsObserver; it usually wasn't created, afaict.
Ash prefs were usually registered with chrome too late in local tests.
(they are available on first sign-in for some unknown timing reason)

Inline behavior in ChromeLauncherController::OnIsSyncingChanged.
Wait for OnIsSyncingChanged to check for pref registration and init.
Timing still isn't guaranteed, but this moves the needle in our favor.

TODO: Init prefs in Ash for guaranteed ordering - crbug.com/774657

Bug: 753823,774657
Change-Id: Ia9a0e4a8a512d50a414b331f39ad72194d1357f6
Reviewed-on: https://chromium-review.googlesource.com/717476
Commit-Queue: Michael Wasserman <msw@chromium.org>
Reviewed-by: James Cook <jamescook@chromium.org>
Cr-Commit-Position: refs/heads/master@{#509079}
[modify] https://crrev.com/7e440443c0dd5d86061c4084e0964605c8724c2b/ash/shelf/shelf_controller.cc
[modify] https://crrev.com/7e440443c0dd5d86061c4084e0964605c8724c2b/chrome/browser/ui/ash/chrome_launcher_prefs.cc
[modify] https://crrev.com/7e440443c0dd5d86061c4084e0964605c8724c2b/chrome/browser/ui/ash/chrome_launcher_prefs.h
[modify] https://crrev.com/7e440443c0dd5d86061c4084e0964605c8724c2b/chrome/browser/ui/ash/launcher/chrome_launcher_controller.cc
[modify] https://crrev.com/7e440443c0dd5d86061c4084e0964605c8724c2b/chrome/browser/ui/ash/launcher/chrome_launcher_controller.h

Is this still in need of further attention?

Yes, my CL above only made the shelf pref init problems less likely to occur.
Remote mojo PrefService users should be notified when pref syncing has started.
See my first comment that explains the issue in more detail.
Help from someone that knows prefs/sync well is appreciated!

The mojo PrefService's client has the concept of a local write-through cache as part of the client. https://docs.google.com/document/d/1JU8QUWxMEXWMqgkvFUumKSxr7Z-nfq0YvreSJTkMVmU/edit#heading=h.h4s95ei8yxde

Is there anything missing from the sync side to support those use cases?

This bug is specifically about mojo apps knowing when pref values have been obtained from sync.
ie. on first sign-in, local shelf prefs are initialized from synced values; Ash should do that, not Chrome.
See the original comment for additional details, any help here would be much appreciated.

I'm not familiar enough with the mojo PrefService design. But if that's a valid use case, then exposing functionality like PrefServiceSyncable::IsPrioritySyncing() or PrefServiceSyncable::IsPrefSynced() sounds like a solution.

I'm unassigning myself as this looks like a prefservice feature request and less of a sync feature request (if it's correct that PrefServiceSyncable has the required functionality).

sync-triage ping: this issue in quite old and doesn't have an owner, maybe it should be P3?

FWIW, it's still relevant and would be nice to fix.

about Comment12: I don't think this is a sync service issue (sync-triage shouldn't apply here). Removing Services > Sync component.