[MD Settings] Stop prefs singleton firing change events at initialization

[MD Settings] Stop prefs singleton firing change events at initialization

settings-prefs-singleton relies on settings-prefs instances to see changes
made by the UI. shared-prefs forwards these changes by observing "prefs.*"
and firing a custom event including the change record.

The custom event was named "prefs-changed", which is the same name as
an event fired by Polymer when "this.prefs" is set. So, we were observing
both "prefs.*" and "prefs" in one function, but those events have different
arguments.

Use a different name ("shared-prefs-changed") for this.

The shared-prefs instances still need to listen to changes coming from the
singleton, so we have settings-prefs-singleton manually fire the prefs-changed
event when its prefs change.

Committed: https://crrev.com/6547a5017257ded6d8a4dc04dc7a1879c41c2209
Cr-Commit-Position: refs/heads/master@{#364889}

[michaelpg, 2015-12-12 00:15:59]

Description was changed from

==========
[MD Settings] Stop prefs singleton firing change events at initialization

settings-prefs-singleton relies on settings-prefs instances to see changes
made by the UI. shared-prefs forwards these changes by observing "prefs.*"
and firing a custom event including the change record.

The custom event was named "prefs-changed", which is the same name as
an event fired by Polymer when "this.prefs" is set. So, we were observing
both "prefs.*" and "prefs" in one function, but those events have different
arguments.

settings-prefs-singleton doesn't care when "this.prefs" is set (only happens
during initialization), so stop listening to "prefs-changed".
==========

to

==========
[MD Settings] Stop prefs singleton firing change events at initialization

settings-prefs-singleton relies on settings-prefs instances to see changes
made by the UI. shared-prefs forwards these changes by observing "prefs.*"
and firing a custom event including the change record.

The custom event was named "prefs-changed", which is the same name as
an event fired by Polymer when "this.prefs" is set. So, we were observing
both "prefs.*" and "prefs" in one function, but those events have different
arguments.

Use a different name ("shared-prefs-changed") for this.

The shared-prefs instances still need to listen to changes coming from the
singleton, so we have settings-prefs-singleton manually fire the prefs-changed
event when its prefs change.
==========

[michaelpg, 2015-12-12 00:15:59]

michaelpg@chromium.org changed reviewers:
+ dschuyler@chromium.org, stevenjb@chromium.org

[michaelpg, 2015-12-12 00:17:17]

PTAL.

If you want to understand this better, I have a fiddle:
https://jsfiddle.net/qww5ccym/2/

But probably the end goal should be to simplify the actual code.

[stevenjb, 2015-12-12 00:23:40]

lgtm

[dschuyler, 2015-12-12 00:37:45]

lgtm

[michaelpg, 2015-12-12 00:43:03]

The CQ bit was checked by michaelpg@chromium.org

[commit-bot: I haz the power, 2015-12-12 00:47:21]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1515033004/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1515033004/20001

[commit-bot: I haz the power, 2015-12-12 02:53:41]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-12-12 02:53:41]

Try jobs failed on following builders:
  android_chromium_gn_compile_dbg on tryserver.chromium.linux (JOB_TIMED_OUT, no
build URL)
  android_clang_dbg_recipe on tryserver.chromium.linux (JOB_TIMED_OUT, no build
URL)
  cast_shell_android on tryserver.chromium.linux (JOB_TIMED_OUT, no build URL)
  linux_chromium_chromeos_compile_dbg_ng on tryserver.chromium.linux
(JOB_TIMED_OUT, no build URL)
  linux_chromium_chromeos_ozone_rel_ng on tryserver.chromium.linux
(JOB_TIMED_OUT, no build URL)
  linux_chromium_compile_dbg_32_ng on tryserver.chromium.linux (JOB_TIMED_OUT,
no build URL)
  linux_chromium_rel_ng on tryserver.chromium.linux (JOB_TIMED_OUT, no build
URL)

[michaelpg, 2015-12-12 03:00:35]

The CQ bit was checked by michaelpg@chromium.org

[commit-bot: I haz the power, 2015-12-12 03:04:24]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1515033004/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1515033004/20001

[commit-bot: I haz the power, 2015-12-12 03:52:33]

Description was changed from

==========
[MD Settings] Stop prefs singleton firing change events at initialization

settings-prefs-singleton relies on settings-prefs instances to see changes
made by the UI. shared-prefs forwards these changes by observing "prefs.*"
and firing a custom event including the change record.

The custom event was named "prefs-changed", which is the same name as
an event fired by Polymer when "this.prefs" is set. So, we were observing
both "prefs.*" and "prefs" in one function, but those events have different
arguments.

Use a different name ("shared-prefs-changed") for this.

The shared-prefs instances still need to listen to changes coming from the
singleton, so we have settings-prefs-singleton manually fire the prefs-changed
event when its prefs change.
==========

to

==========
[MD Settings] Stop prefs singleton firing change events at initialization

settings-prefs-singleton relies on settings-prefs instances to see changes
made by the UI. shared-prefs forwards these changes by observing "prefs.*"
and firing a custom event including the change record.

The custom event was named "prefs-changed", which is the same name as
an event fired by Polymer when "this.prefs" is set. So, we were observing
both "prefs.*" and "prefs" in one function, but those events have different
arguments.

Use a different name ("shared-prefs-changed") for this.

The shared-prefs instances still need to listen to changes coming from the
singleton, so we have settings-prefs-singleton manually fire the prefs-changed
event when its prefs change.
==========

[commit-bot: I haz the power, 2015-12-12 03:52:34]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-12-12 03:53:13]

Description was changed from

==========
[MD Settings] Stop prefs singleton firing change events at initialization

settings-prefs-singleton relies on settings-prefs instances to see changes
made by the UI. shared-prefs forwards these changes by observing "prefs.*"
and firing a custom event including the change record.

The custom event was named "prefs-changed", which is the same name as
an event fired by Polymer when "this.prefs" is set. So, we were observing
both "prefs.*" and "prefs" in one function, but those events have different
arguments.

Use a different name ("shared-prefs-changed") for this.

The shared-prefs instances still need to listen to changes coming from the
singleton, so we have settings-prefs-singleton manually fire the prefs-changed
event when its prefs change.
==========

to

==========
[MD Settings] Stop prefs singleton firing change events at initialization

settings-prefs-singleton relies on settings-prefs instances to see changes
made by the UI. shared-prefs forwards these changes by observing "prefs.*"
and firing a custom event including the change record.

The custom event was named "prefs-changed", which is the same name as
an event fired by Polymer when "this.prefs" is set. So, we were observing
both "prefs.*" and "prefs" in one function, but those events have different
arguments.

Use a different name ("shared-prefs-changed") for this.

The shared-prefs instances still need to listen to changes coming from the
singleton, so we have settings-prefs-singleton manually fire the prefs-changed
event when its prefs change.

Committed: https://crrev.com/6547a5017257ded6d8a4dc04dc7a1879c41c2209
Cr-Commit-Position: refs/heads/master@{#364889}
==========

[commit-bot: I haz the power, 2015-12-12 03:53:16]

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