[MD Settings] Add feature to enable md-settings by default.

[MD Settings] Add feature to enable md-settings by default.

Adds a flag that allows serving md-settings under chrome://md-settings.
Old settings will still be served under chrome://legacy-settings when
this is enabled.

BUG=614758

[groby-ooo-7-16, 2016-06-01 01:54:25]

Description was changed from

==========
[MD Settings] Add feature to enable md-settings by default.

Adds a flag that allows serving md-settings under chrome://md-settings.
Old settings will still be served under chrome://legacy-settings when
this is enabled.

BUG=614758
==========

to

==========
[MD Settings] Add feature to enable md-settings by default.

Adds a flag that allows serving md-settings under chrome://md-settings.
Old settings will still be served under chrome://legacy-settings when
this is enabled.

BUG=614758
==========

[groby-ooo-7-16, 2016-06-01 01:54:25]

groby@chromium.org changed reviewers:
+ dbeam@chromium.org

[groby-ooo-7-16, 2016-06-01 01:56:08]

It's still WIP, just to give you an idea of the direction it's heading.

Essentially, I'll add a feature flag that'll switch behavior of
GetLegacySettingsHost/GetMdSettingsHost, and that should be the rough gist of
it.

As long as legacy settings still returns chrome://settings, this change should
have no logic changes.

[Dan Beam, 2016-06-01 17:49:18]

this is not what we talked about

we talked about: settings-frame being the "legacy" host, md-settings staying the
"always new" host, and chrome://settings flipping it's meaning

we should not be introducing new URLs or methods to deal with those URLs

[groby-ooo-7-16, 2016-06-01 17:54:00]

On 2016/06/01 17:49:18, Dan Beam wrote:
> this is not what we talked about
> 
> we talked about: settings-frame being the "legacy" host, md-settings staying
the
> "always new" host, and chrome://settings flipping it's meaning
> 
> we should not be introducing new URLs or methods to deal with those URLs

If you want chrome://settings to flip its meaning, you'd need to introduce an
entire new uber page to host settings-frame. Or, alternatively, make the URL
rewriting contingent on the flag. How's that better than introducing a new URL?

[Dan Beam, 2016-06-01 18:03:22]

On 2016/06/01 17:54:00, groby wrote:
> On 2016/06/01 17:49:18, Dan Beam wrote:
> > this is not what we talked about
> > 
> > we talked about: settings-frame being the "legacy" host, md-settings staying
> the
> > "always new" host, and chrome://settings flipping it's meaning
> > 
> > we should not be introducing new URLs or methods to deal with those URLs
> 
> If you want chrome://settings to flip its meaning, you'd need to introduce an
> entire new uber page to host settings-frame. Or, alternatively, make the URL
> rewriting contingent on the flag. How's that better than introducing a new
URL?

see what we do for history -- remove the nav entry from the uber page when md is
the default, and just let those using the escape hatch navigate to
settings-frame directly

[groby-ooo-7-16, 2016-06-01 20:46:55]

On 2016/06/01 18:03:22, Dan Beam wrote:
> On 2016/06/01 17:54:00, groby wrote:
> > On 2016/06/01 17:49:18, Dan Beam wrote:
> > > this is not what we talked about
> > > 
> > > we talked about: settings-frame being the "legacy" host, md-settings
staying
> > the
> > > "always new" host, and chrome://settings flipping it's meaning
> > > 
> > > we should not be introducing new URLs or methods to deal with those URLs
> > 
> > If you want chrome://settings to flip its meaning, you'd need to introduce
an
> > entire new uber page to host settings-frame. Or, alternatively, make the URL
> > rewriting contingent on the flag. How's that better than introducing a new
> URL?
> 
> see what we do for history -- remove the nav entry from the uber page when md
is
> the default, and just let those using the escape hatch navigate to
> settings-frame directly

Done in https://codereview.chromium.org/2029263002/ - closing this.