Added repro screenshots

Deleted: 1) Add 3 extensions to GPO.png 162 KB

	1) Add 3 extensions to GPO.png 162 KB View Download

Deleted: 2) They show up sequentially in registry.png 22.9 KB

	2) They show up sequentially in registry.png 22.9 KB View Download

Deleted: 3) Change sequential order or registry items manually.png 161 KB

	3) Change sequential order or registry items manually.png 161 KB View Download

Deleted: 4) Policy ignores registry items after cutoff.png 18.7 KB

	4) Policy ignores registry items after cutoff.png 18.7 KB View Download

untriaged w/ owner -> assigned

Georges, can you take a look?   

IIUC, this happens with other Chrome policies and I'd like to understand if this is a Chrome thing or a GPO limitation.

I think it's due to limitation of GPO/Windows which pastarmovj@ have mentioned before.

If this is windows/gpo limitation we can close this as WIA.  

Well we can make change our code to be able to skip over holes in the numbering. This is not going to be a valid registry configuration in the sense of what will be produced if the policies are only ever edited with the group policy editor but we can do it.

The question is do we want to?

As for the technical feasibility it is a relatively trivial change to the policy::ConvertValue and RegistryDict::ConvertToJSON functions in the registry_dict_win.cc file.

IMO, fixing this would be a positive.

There are many admins out there populating registries via script or 3rd party tools (instead of GP editor) that may be prone to error.

@blumberg, your thoughts?

My suggestion is displaying the error on the chrome://policy page instead of ignoring it. Fixing the error should not be hard for admins as long as we tell them.

 
It sounds like we have 2 paths forward:

1.  Don't make a change to how we process the policies and add a error message in chrome:policy per Owen's recc.
2.  Make this trivial change to support gaps in the policy list (eg, you have 10 extensions to force-install but there is a blank line after item 5 so only extensions 1,2,3,4 get installed and 6-10 are ignored. 

Julian, my question is about the risk if we do make the change:

 Is there risk for customers that use both group policy editor (the native MS tool) for creation/management/deployment of entries AS WELL AS direct registry modifications manually/via script or other tool? Can you clarify what the expected behavior will be for a customer that has a gap in their list today before/after this change along with the expected behavior for customers that manage via registry and other tools (in addition to GPO)? Not 100% clear on #c7.
 

I think no admin in their right mind will mix the policy editor with manual changes because the GPO application will wipe over his manual registry key changes. I guess it is either one and potentially some 3rd party tools which might also be leaving gaps.

There is no risk in modifying the code to be able to skip numbers or even read any key regardless whether its name is a number or not. I think when this code was written the standard behavior of the GPO editor was used as a template and the edge case was simply never covered.

Adding code to check about this situation for the sake of showing a warning on the policy page or simply reading through seems to be similar effort imo.

#2 is the more durable solution, but it could technically have adverse effects (although the chances are low). If an admin is running a configuration with a blank line and there's a following entry that has an impactful effect that was never activated, our change will have sudden and potentially unexpected impact for those users.

I still think we should go ahead with #2, as the positives largely outweigh the negatives. Assigning it to myself.

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

commit 1a839edc0bc326d05f368ff00ce5a9e3b10d3041
Author: georgesak <georgesak@chromium.org>
Date: Fri Nov 04 13:09:38 2016

Enable non-sequential entries when loading registry lists.

This CL makes the loading much more permissive. The names still have to be integers, but need not be sequential.

BUG= 655774 

Review-Url: https://codereview.chromium.org/2478503002
Cr-Commit-Position: refs/heads/master@{#429870}

[modify] https://crrev.com/1a839edc0bc326d05f368ff00ce5a9e3b10d3041/components/policy/core/common/registry_dict_win.cc
[modify] https://crrev.com/1a839edc0bc326d05f368ff00ce5a9e3b10d3041/components/policy/core/common/registry_dict_win_unittest.cc

Hi georgesak,

Thanks for the fix!
Do we know which version of Chrome this will land in so I can set expectations with the customer?

This will be in M56.

Anyway way we can get this merged to 55?.

This is needed for a large customer that currently has 53 deployed in their environment.  I believe they would be hesitant to move to dev channel in production.

@georgesak, can this be merged to r55?  Large customer is waiting for this fix but doesn't want to move all clients to 56.

Friendly ping.. 

Can this be merged to r55?  

Apologies, I meant to answer this earlier but got sidetracked.

Merging to M55 will not be possible (not a blocker/security issue).

It will be in M56 however.

Thanks for the response.
Fair enough, I will communicate that w/ the customer.