I agree something here probably needs to change.  The question is what should proper behavior be.  There are also a few other things to bear in mind.
* Some extensions are device-specific.  If a user has these, syncing the length alone would mean a different set of extensions is shown for different machines if the same length is enforced.
* Since different devices have different screen real-estate, it's not totally uncommon to want a different number of extensions shown/hidden.  e.g., on a 14" laptop, I might want some less-commonly-used extensions overflowed, but on a 24" desktop monitor, I'd be more willing to give up the UI space.  I think this was the original reason the pref wasn't synced.

I can think of three semi-reasonable options (though there are probably more):

1. Sync the length, and people just have to deal with the weirdness of policy vs non policy or device-specific extension funniness. Since most (sync) users probably don't have many device-specific extensions, this would realistically solve the problem for most people, and would at least provide the better out-of-the-box experience.  It's also a really easy fix.  But it wouldn't allow different extensions to be visible/overflowed on different machines.

2. Sync a per-extension visible/overflowed pref.  This would address the issue of per-device extensions being properly hidden/shown, but also wouldn't address the use case of having more extensions visible when there's more UI real estate.

3. Don't sync length so that users can choose which extensions are visible on which device (what we have now).

Note that 2 would also problems like  issue 599362 .

Any thoughts, folks?

Because devices can have difference resolutions, along with different extensions, I agree syncing can cause trouble. I would only advocate syncing the *initial* state.

Whatever we decide to sync (length or per-extension bits), the user can update the server's values any time they change this, but the server's values will only be applied to newly added devices. This is similar to how we sync input methods which are also device dependent: https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/chromeos/input_method/input_method_syncer.h

Is the *ordering* of extensions in the toolbar synced today?

If so, a good rule might be "show all icons up to and including the highest-ordered visible icon from any device".

So if my two devices have these toolbars:

  [Ext1]  [Ext2]  [PolicyExt3]  [Ext4]  |  (overflow: Ext5, PolicyExt6, Ext7)
  [Ext1]  [Ext2]  [Ext4]        [Ext5]  |  (overflow: Ext7)

then any new device should show all extension icons up to and including Ext5, regardless of whether the policy extensions are also present. This way we don't hide more icons than the longest toolbar, but we don't extend the extension toolbar ridiculously and make the OOBE omnibox super short if we don't have to.


I wonder if a good rule might be "show all icons up to the 

My 2 cents:

I specifically don't like the thought of implementing approach 1) (from comment 1). Having only one toolbar size per device class (let alone one toolbar size for all devices) is a deal breaker. 

I'd be hesitant to implement 2) given that it leads to issues that are probably worse than what we're trying to fix.

Another thing to keep in mind is that we've also had an impetus to surface extensions better to users and showing them all when you initialize a new machine is very much in line with that, I guess. (shrug) :)

But having said that, I wouldn't object to finding some reasonable value to set the initial state to. I'd be OK, I think, with what's suggested in comment 3 if it doesn't add a lot of complexity.

 Issue 611059  has been merged into this issue.

 Issue 670011  has been merged into this issue.