Update extension preference API.

Update extension preference API.

Modify Boolean extension preference "networkPredictionEnabled" to interact with native browser preference |prefs::kNetworkPredictionOptions| instead of obsolete |prefs::kNetworkPredictionEnabled|.

BUG=423748
Committed: https://crrev.com/2fcb4c342e0a05ab2b5449cc14e52d47a91ebf89
Cr-Commit-Position: refs/heads/master@{#300723}

[Bence, 2014-10-13 19:48:26]

bnc@chromium.org changed reviewers:
+ mek@chromium.org, phajdan.jr@chromium.org

[Bence, 2014-10-13 19:48:26]

mek: PTAL at chrome/browser, chrome/common.
phajdan.jr: PTAL chrome/test.

Note that this draft replaces the obsolete preference with the new one.  Is
there a need to provide backward compatibility for extensions that use the old
preference?  If so, where would I put the logic to translate
"networkPredictionEnabled" (true, false) into "networkPredictionOptions" (ALWAYS
(or WIFI_ONLY), NEVER)?

Thanks.

[Marijn Kruisselbrink, 2014-10-13 20:50:04]

On 2014/10/13 19:48:26, Bence wrote:
> mek: PTAL at chrome/browser, chrome/common.
> phajdan.jr: PTAL chrome/test.
> 
> Note that this draft replaces the obsolete preference with the new one.  Is
> there a need to provide backward compatibility for extensions that use the old
> preference?  If so, where would I put the logic to translate
> "networkPredictionEnabled" (true, false) into "networkPredictionOptions"
(ALWAYS
> (or WIFI_ONLY), NEVER)?
> 
> Thanks.
I would say that yes, we should aim for backward compatibility. I don't know
exactly how this code works (but I can find out), but for a start it seems like
src/chrome/browser/extensions/api/preference/preference_api.cc might be related
(and would need updating anyway). That file seems to have the concept of
Preference Transformers to transform a setting from one representation to
another, maybe that can be used for the logic to translate one into the other?

[Bence, 2014-10-14 15:17:48]

Marijn:  Thank you for your pointers.  I'm stuck!  The way |PrefMapping| class
is currently implemented only allows for a single extension preference for each
browser preference.  (|mapping_| and |transformers_| are |std::map|,
|PreferenceEventRouter::OnPrefChanged| only sends a single
|DispatchEventToExtensions|, etc.)  I would ideally want both
"networkPredictionEnabled" and "networkPredictionOptions" extension preferences
to be mapped to |prefs::kNetworkPredictionOptions|.  Shall I rewrite
|PrefMapping| and |PreferenceEventRouter| to accomodate for this?

[Paweł Hajdan Jr., 2014-10-16 15:23:42]

chrome/test LGTM

[Bence, 2014-10-16 19:04:32]

bnc@chromium.org changed reviewers:
- phajdan.jr@chromium.org

[Bence, 2014-10-16 19:56:08]

Marijn: PTAL.  I modified the extension preference to make it backward
compatible, and intend to submit this CL at this stage.  If the need for finer
control through an additional extension preference emerges, I'll work on it in a
separate CL.  I'm still waiting for feedback on this at
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-apps/27eu9Y16bfs.
 Thank you.

[Bence, 2014-10-20 14:20:30]

ping Marijn

[Bence, 2014-10-21 20:55:46]

Marijn: PTAL.

[Marijn Kruisselbrink, 2014-10-22 16:47:21]

sorry for the delay, lgtm

[Bence, 2014-10-22 17:36:06]

The CQ bit was checked by bnc@chromium.org

[commit-bot: I haz the power, 2014-10-22 17:39:11]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/652013002/160001

[commit-bot: I haz the power, 2014-10-22 18:48:26]

Committed patchset #2 (id:160001)

[commit-bot: I haz the power, 2014-10-22 18:50:22]

Patchset 2 (id:??) landed as
https://crrev.com/2fcb4c342e0a05ab2b5449cc14e52d47a91ebf89
Cr-Commit-Position: refs/heads/master@{#300723}

[grt (UTC plus 2), 2014-10-22 20:50:22]

A revert of this CL (patchset #2 id:160001) has been created in
https://codereview.chromium.org/670223002/ by grt@chromium.org.

The reason for reverting is: Broke ExtensionPreferenceApiTest.Standard on
multiple builders..