My understanding was that AD sync wouldn't necessarily de-dupe preferences that remained the same, especially for complex preferences (more than just bools)

Hrm. I couldn't find the AD sync code at a quick glance. I think we're looking for PrefValueStore::PrefStoreKeeper::OnPrefValueChanged callers. There's a lot of them though.

Better idea: Preferences folks, is the expectation that we need to check for changes when the NamedChangeCallback we pass into PrefMemberBase::Init is called, or will you all take care of that before calling it? We need to perform a fairly expensive operation when this happens for SSL prefs, so we need to avoid spurious changes.

Note that ChromeOS's proxy config stuff is pretty scary.  It's also a possible source of duplicate messages (And it can be controlled by extensions, I think?)

So whether the check reliably happens today or not, it seems the best place for the check to be. The prefs system knows what keys it is claiming to have changed, and base::Value knows how to compare for equality. And indeed most codepaths through OnPrefValueChanged do check for changes here. But, yeah, I don't know how reliable this is right now.

+battre from components/prefs/OWNERS, could you answer the question in comment #2?

Ping for battre :)

I am pretty confident that today you only get notified if the the value changes but I am not sure whether this is architecturally sufficiently enforced and tested so that this could not change. The responsibility is spread over many PrefStores.

Could we add it to the interface's requirements and perhaps add suitable tests? It's a huge drawback to this system's usability right now.

My take is the same as #7 and I'm supportive of #8. Prefs is in maintenance mode right now though (owners are all working on other things) but we'd sure welcome stronger API contracts and test improvements if you want to send us CLs.

AFAICT components/prefs/pref_change_registrar_unittest.cc is what tests pref observation, but there doesn't appear to be integration testing that this works on the real world PrefService composed of many PrefStores (and whether the notification fires when the value changes in the effective store for all stores -- e.g. policy).

So, what's the path forward here? It looks like the details are all in the individual stores (which makes sense as those stores are the ones that control when something changed), so it's not clear how one would test this overall.

Independent of who all will be doing the CLs, roughly what kind of change were you thinking of to strengthen API contract? I could certainly just add a comment, but I'm not sure that's what you had in mind.

Another possibility is we add no-op change tests on a case-by-case basis based on just the couple of stores for which this is most important and call it good enough. Which stores are these?