Comment #26 on issue 125467 by
bart...@chromium.org: GPO to
Comment 9 gives the crucial hint here: We are dealing with a regression.
This used to work in Chrome 18 but broke in Chrome 19. Leaving policies
aside for the moment, I experimented with the following master_preferences:
first_run_tabs
session.restore_on_startup
session.urls_to_restore_on_startup
For each experiment, I started Chrome with a fresh profile. Here is what I
got:
Default behavior
=================================================
Chrome 18 Chrome 19
* Sync promo * Sync promo
* Welcome page * Welcome page
-> first_run_tabs = ["URL_A"]
=================================================
Chrome 18 Chrome 19
* Sync promo * Sync promo
* URL_A * URL_A
-> session.restore_on_startup = 4
-> session.urls_to_restore_on_startup = ["URL_B"]
=================================================
Chrome 18 Chrome 19
* URL_B * Sync promo
* Welcome page
-> first_run_tabs = ["URL_A"]
-> session.restore_on_startup = 4
-> session.urls_to_restore_on_startup = ["URL_B"]
=================================================
Chrome 18 Chrome 19
* URL_B * Sync promo
* URL_A
So, when you tell Chrome 18 to restore a specific set of URLs on start-up
(which can be done via master_preferences or via the corresponding policy),
the right thing happens: You get these URLs and nothing but. Chrome 19
ignores the setting completely. Here, you have to set first_run_tabs to the
desired URLs instead and you have to use
sync_promo.show_on_first_run_allowed to turn off the sync promo. Neither of
these prefs is exposed as a policy. Rather than adding such policies, we
should fix the regression:
When URLs to restore are configured via master_preferences or policy, skip
the sync promo and welcome page, showing these URLs only. This would make
Chrome 18 and 19 behave identically in experiments 1, 2, 3 above. To fix
experiment 4, the URLs to restore should additionally take precedence over
the first_run_tabs pref as they did in Chrome 18.