Material WebUI: cr-slider element for intelligent range mapping

Material WebUI: cr-slider element for intelligent range mapping

Most sliders don't correspond 1:1 with a range of values. For instance,
we curate a range of valid values for pointer sensitivity, then map these
to a linear slider.

<cr-slider> takes an array of values corresponding to slider indices, and
binds the value of the <paper-slider> it wraps to the host element's property.

This simplifies the logic that was duplicated in keyboard.html and
appearance_fonts_page.html. It also fixes a rare edge case when a pref value
updates while the slider is being dragged.

BUG=611949
TEST=CrElementsBrowserTest.CrElements
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation

Committed: https://crrev.com/d326605487da452867181c1fe0dc7c6580b0d714
Cr-Commit-Position: refs/heads/master@{#397517}

[michaelpg, 2016-05-11 00:12:35]

Description was changed from

==========
Material WebUI: SliderHostBehavior for elements that host sliders

Most sliders don't correspond 1:1 with a range of values. For instance,
we curate a range of valid values for pointer sensitivity, then map these
to a linear slider.

This generalizes that behavior so any element can host a <paper-slider>
and specify what its indices should map to, providing a semblance of
two-way data binding.

NOSUBMIT=true # tests
BUG= # todo
==========

to

==========
Material WebUI: SliderHostBehavior for elements that host sliders

Most sliders don't correspond 1:1 with a range of values. For instance,
we curate a range of valid values for pointer sensitivity, then map these
to a linear slider.

This generalizes that behavior so any element can host a <paper-slider>
and specify what its indices should map to, providing a semblance of
two-way data binding.

NOSUBMIT=true # tests
BUG= # todo
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

[michaelpg, 2016-05-11 00:14:21]

Please take a quick look at slider_host_behavior.js. This is
the simplest I could come up with. It could be easier to use
(a paper-slider is now 10 lines of HTML) but that requires
doing tricky things with data binding that Polymer doesn't like.

I'll add tests.

[stevenjb, 2016-05-11 16:37:40]

stevenjb@chromium.org changed reviewers:
+ stevenjb@chromium.org

[stevenjb, 2016-05-11 16:37:41]

I'm a little concerned that we may be over-optimizing here. This seems like a
strong use case for a <settings-slider> element. I would almost see us
copy/paste behavior and layout from <paper-slider> if we are concerned with the
overhead of embedding elements.

https://codereview.chromium.org/1967913002/diff/1/chrome/browser/resources/se...
File chrome/browser/resources/settings/device_page/keyboard.html (right):

https://codereview.chromium.org/1967913002/diff/1/chrome/browser/resources/se...
chrome/browser/resources/settings/device_page/keyboard.html:74:
data-value-path="prefs.settings.language.xkb_auto_repeat_delay_r2.value"
nit: split line (here and below)?

https://codereview.chromium.org/1967913002/diff/1/ui/webui/resources/cr_eleme...
File ui/webui/resources/cr_elements/slider/slider_host_behavior.js (right):

https://codereview.chromium.org/1967913002/diff/1/ui/webui/resources/cr_eleme...
ui/webui/resources/cr_elements/slider/slider_host_behavior.js:78: // TODO
TODO?

[michaelpg, 2016-05-14 04:29:32]

Description was changed from

==========
Material WebUI: SliderHostBehavior for elements that host sliders

Most sliders don't correspond 1:1 with a range of values. For instance,
we curate a range of valid values for pointer sensitivity, then map these
to a linear slider.

This generalizes that behavior so any element can host a <paper-slider>
and specify what its indices should map to, providing a semblance of
two-way data binding.

NOSUBMIT=true # tests
BUG= # todo
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

to

==========
Material WebUI: cr-slider element for intelligent range mapping

Most sliders don't correspond 1:1 with a range of values. For instance,
we curate a range of valid values for pointer sensitivity, then map these
to a linear slider.

<cr-slider> takes an array of values corresponding to slider indices, and
binds the value of the <paper-slider> it wraps to the host element's property.

BUG= # todo
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

[michaelpg, 2016-05-14 04:29:33]

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

[michaelpg, 2016-05-14 04:43:00]

Description was changed from

==========
Material WebUI: cr-slider element for intelligent range mapping

Most sliders don't correspond 1:1 with a range of values. For instance,
we curate a range of valid values for pointer sensitivity, then map these
to a linear slider.

<cr-slider> takes an array of values corresponding to slider indices, and
binds the value of the <paper-slider> it wraps to the host element's property.

BUG= # todo
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

to

==========
Material WebUI: cr-slider element for intelligent range mapping

Most sliders don't correspond 1:1 with a range of values. For instance,
we curate a range of valid values for pointer sensitivity, then map these
to a linear slider.

<cr-slider> takes an array of values corresponding to slider indices, and
binds the value of the <paper-slider> it wraps to the host element's property.

This simplifies the logic that was duplicated in keyboard.html and
appearance_fonts_page.html. It also fixes a rare edge case when a pref value
updates while the slider is being dragged.

BUG=611949
TEST=CrElementsBrowserTest.CrElements
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

[michaelpg, 2016-05-14 04:44:34]

On 2016/05/11 16:37:41, stevenjb wrote:
> I'm a little concerned that we may be over-optimizing here. This seems like a
> strong use case for a <settings-slider> element. I would almost see us
> copy/paste behavior and layout from <paper-slider> if we are concerned with
the
> overhead of embedding elements.

I modified the CL to create a <cr-slider>. This simplifies the logic quite a
bit,
at the expense of hiding the real slider within a new component. This brings
about
the same difficulties we have with our other cr-elements, like projecting events
and ARIA properties between the host and the wrapped slider, but we'll have to
solve that later.

https://codereview.chromium.org/1967913002/diff/1/chrome/browser/resources/se...
File chrome/browser/resources/settings/device_page/keyboard.html (right):

https://codereview.chromium.org/1967913002/diff/1/chrome/browser/resources/se...
chrome/browser/resources/settings/device_page/keyboard.html:74:
data-value-path="prefs.settings.language.xkb_auto_repeat_delay_r2.value"
On 2016/05/11 16:37:40, stevenjb wrote:
> nit: split line (here and below)?

meh. sometimes it helps, sometimes it doesn't, and splitting after = looks
weird/messy.

[michaelpg, 2016-05-16 04:39:57]

Patchset #4 (id:60001) has been deleted

[michaelpg, 2016-05-16 04:50:01]

michaelpg@chromium.org changed required reviewers:
+ stevenjb@chromium.org

[michaelpg, 2016-05-16 04:50:01]

+dschuyler as fyi, input on slider & font stuff is welcome tho

[dschuyler, 2016-05-16 20:49:50]

https://codereview.chromium.org/1967913002/diff/80001/chrome/browser/resource...
File chrome/browser/resources/settings/appearance_page/appearance_fonts_page.js
(right):

https://codereview.chromium.org/1967913002/diff/80001/chrome/browser/resource...
chrome/browser/resources/settings/appearance_page/appearance_fonts_page.js:154:
// TODO(dschuyler): Actually fetch this pref so setting it does something.
A TODO should have the name of the person who wrote the
todo (or someone who can explain the comment furture --
I'm not sure what the comment is saying).

[stevenjb, 2016-05-16 21:57:51]

Much nicer as a separate custom element I think, thanks.

https://codereview.chromium.org/1967913002/diff/80001/chrome/browser/resource...
File
chrome/browser/resources/settings/appearance_page/appearance_fonts_page.html
(right):

https://codereview.chromium.org/1967913002/diff/80001/chrome/browser/resource...
chrome/browser/resources/settings/appearance_page/appearance_fonts_page.html:48:
<span>[[prefs.webkit.webprefs.default_font_size.value]]</span>:&nbsp;
wrapping on all these lines (also, how are these changes related to cr-slider?)

https://codereview.chromium.org/1967913002/diff/80001/chrome/browser/resource...
File chrome/browser/resources/settings/appearance_page/appearance_fonts_page.js
(right):

https://codereview.chromium.org/1967913002/diff/80001/chrome/browser/resource...
chrome/browser/resources/settings/appearance_page/appearance_fonts_page.js:154:
// TODO(dschuyler): Actually fetch this pref so setting it does something.
On 2016/05/16 20:49:50, dschuyler wrote:
> A TODO should have the name of the person who wrote the
> todo (or someone who can explain the comment furture --
> I'm not sure what the comment is saying).

FWIW, it's OK to put someone else's name on a TODO, but they should review it
and understand what you mean :) It is also useful to have an issue associated
witha TODO.

[michaelpg, 2016-05-17 19:18:43]

PTAL.

https://codereview.chromium.org/1967913002/diff/80001/chrome/browser/resource...
File
chrome/browser/resources/settings/appearance_page/appearance_fonts_page.html
(right):

https://codereview.chromium.org/1967913002/diff/80001/chrome/browser/resource...
chrome/browser/resources/settings/appearance_page/appearance_fonts_page.html:48:
<span>[[prefs.webkit.webprefs.default_font_size.value]]</span>:&nbsp;
On 2016/05/16 21:57:51, stevenjb wrote:
> wrapping on all these lines

Done.

> (also, how are these changes related to cr-slider?)

we don't need a proxy for the pref anymore, defaultFontSize_ is redundant.
previously we used the pref to update defaultFontSize_ to update the UI, then
fontSizeIndex_ to update the pref in response to the UI.

now we use the pref to update the UI, and the UI to update the pref.

Same argument for minimum font size.

https://codereview.chromium.org/1967913002/diff/80001/chrome/browser/resource...
File chrome/browser/resources/settings/appearance_page/appearance_fonts_page.js
(right):

https://codereview.chromium.org/1967913002/diff/80001/chrome/browser/resource...
chrome/browser/resources/settings/appearance_page/appearance_fonts_page.js:154:
// TODO(dschuyler): Actually fetch this pref so setting it does something.
On 2016/05/16 20:49:50, dschuyler wrote:
> A TODO should have the name of the person who wrote the
> todo (or someone who can explain the comment furture --
> I'm not sure what the comment is saying).

Done.

[stevenjb, 2016-05-17 19:30:36]

I think the tangentially related appearance_fonts_page changes would probably be
better in a follow-up CL, but either way this lgtm.

[Dan Beam, 2016-05-17 19:35:44]

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

[Dan Beam, 2016-05-17 19:35:45]

https://codereview.chromium.org/1967913002/diff/80001/chrome/test/data/webui/...
File chrome/test/data/webui/cr_elements/cr_elements_browsertest.js (right):

https://codereview.chromium.org/1967913002/diff/80001/chrome/test/data/webui/...
chrome/test/data/webui/cr_elements/cr_elements_browsertest.js:26:
'cr_slider_tests.js',
indent off

https://codereview.chromium.org/1967913002/diff/80001/ui/webui/resources/cr_e...
File ui/webui/resources/cr_elements/cr_slider/cr_slider.html (right):

https://codereview.chromium.org/1967913002/diff/80001/ui/webui/resources/cr_e...
ui/webui/resources/cr_elements/cr_slider/cr_slider.html:8: <paper-slider
id="slider" on-change="onSliderChange_"
on-immediate-value-change="onSliderChange_"
80 col wrap

https://codereview.chromium.org/1967913002/diff/80001/ui/webui/resources/cr_e...
ui/webui/resources/cr_elements/cr_slider/cr_slider.html:9:
disabled="[[disabled]]" snaps="[[snaps]]" max-markers="[[maxMarkers]]">
indent off

https://codereview.chromium.org/1967913002/diff/80001/ui/webui/resources/cr_e...
File ui/webui/resources/cr_elements/cr_slider/cr_slider.js (right):

https://codereview.chromium.org/1967913002/diff/80001/ui/webui/resources/cr_e...
ui/webui/resources/cr_elements/cr_slider/cr_slider.js:39: maxMarkers: Number,
where is this used?

https://codereview.chromium.org/1967913002/diff/80001/ui/webui/resources/cr_e...
ui/webui/resources/cr_elements/cr_slider/cr_slider.js:53: this.value =
this.tickValues[index];
is this less clear?

this.value = this.tickValues[this.$.slider.immediateValue];

https://codereview.chromium.org/1967913002/diff/80001/ui/webui/resources/cr_e...
ui/webui/resources/cr_elements/cr_slider/cr_slider.js:72: typeof this.tickValues
== 'undefined') {
can't we just change how this observer is defined such that these are both
defined, i.e.

  observers: ['valueChanged_(value, tickValues)'],

or

  value: {
    type: Number,
    notify: true,
    observer: 'valueChanged_(tickValues)',
  },

does that simplify this code a little bit?

https://codereview.chromium.org/1967913002/diff/80001/ui/webui/resources/cr_e...
ui/webui/resources/cr_elements/cr_slider/cr_slider.js:100: findNearestIndex_:
function(arr, value) {
why is findNearestIndex_ a separate method?

https://codereview.chromium.org/1967913002/diff/80001/ui/webui/resources/cr_e...
ui/webui/resources/cr_elements/cr_slider/cr_slider.js:106: return closestIndex;
why do you want to run both indexOf() and the loop below?  isn't the code
duplicative?  it probably doesn't matter for general performance, just wondering
why we need the extra search.

[dschuyler, 2016-05-18 00:58:41]

https://codereview.chromium.org/1967913002/diff/120001/ui/webui/resources/cr_...
File ui/webui/resources/cr_elements/cr_slider/cr_slider.js (right):

https://codereview.chromium.org/1967913002/diff/120001/ui/webui/resources/cr_...
ui/webui/resources/cr_elements/cr_slider/cr_slider.js:78: // The pref changed
somewhere else (e.g., sync) but we're still holding
Since this is outside of settings and doesn't rely on 
prefs otherwise, consider changing this comment (so it
doesn't mention pref). e.g. the value changed...

[michaelpg, 2016-05-18 17:05:49]

PTAL, thanks.

https://codereview.chromium.org/1967913002/diff/80001/chrome/test/data/webui/...
File chrome/test/data/webui/cr_elements/cr_elements_browsertest.js (right):

https://codereview.chromium.org/1967913002/diff/80001/chrome/test/data/webui/...
chrome/test/data/webui/cr_elements/cr_elements_browsertest.js:26:
'cr_slider_tests.js',
On 2016/05/17 19:35:45, Dan Beam wrote:
> indent off

Done.

https://codereview.chromium.org/1967913002/diff/80001/ui/webui/resources/cr_e...
File ui/webui/resources/cr_elements/cr_slider/cr_slider.html (right):

https://codereview.chromium.org/1967913002/diff/80001/ui/webui/resources/cr_e...
ui/webui/resources/cr_elements/cr_slider/cr_slider.html:8: <paper-slider
id="slider" on-change="onSliderChange_"
on-immediate-value-change="onSliderChange_"
On 2016/05/17 19:35:45, Dan Beam wrote:
> 80 col wrap

Done.

https://codereview.chromium.org/1967913002/diff/80001/ui/webui/resources/cr_e...
ui/webui/resources/cr_elements/cr_slider/cr_slider.html:9:
disabled="[[disabled]]" snaps="[[snaps]]" max-markers="[[maxMarkers]]">
On 2016/05/17 19:35:45, Dan Beam wrote:
> indent off

Done.

https://codereview.chromium.org/1967913002/diff/80001/ui/webui/resources/cr_e...
File ui/webui/resources/cr_elements/cr_slider/cr_slider.js (right):

https://codereview.chromium.org/1967913002/diff/80001/ui/webui/resources/cr_e...
ui/webui/resources/cr_elements/cr_slider/cr_slider.js:39: maxMarkers: Number,
On 2016/05/17 19:35:45, Dan Beam wrote:
> where is this used?

html for paper-slider

https://codereview.chromium.org/1967913002/diff/80001/ui/webui/resources/cr_e...
ui/webui/resources/cr_elements/cr_slider/cr_slider.js:53: this.value =
this.tickValues[index];
On 2016/05/17 19:35:45, Dan Beam wrote:
> is this less clear?
> 
> this.value = this.tickValues[this.$.slider.immediateValue];

Done.

https://codereview.chromium.org/1967913002/diff/80001/ui/webui/resources/cr_e...
ui/webui/resources/cr_elements/cr_slider/cr_slider.js:72: typeof this.tickValues
== 'undefined') {
On 2016/05/17 19:35:45, Dan Beam wrote:
> can't we just change how this observer is defined such that these are both
> defined, i.e.
> 
>   observers: ['valueChanged_(value, tickValues)'],
> 
> or
> 
>   value: {
>     type: Number,
>     notify: true,
>     observer: 'valueChanged_(tickValues)',
>   },
> 
> does that simplify this code a little bit?

Done.

https://codereview.chromium.org/1967913002/diff/80001/ui/webui/resources/cr_e...
ui/webui/resources/cr_elements/cr_slider/cr_slider.js:100: findNearestIndex_:
function(arr, value) {
On 2016/05/17 19:35:45, Dan Beam wrote:
> why is findNearestIndex_ a separate method?

mostly testability and documentability

https://codereview.chromium.org/1967913002/diff/80001/ui/webui/resources/cr_e...
ui/webui/resources/cr_elements/cr_slider/cr_slider.js:106: return closestIndex;
On 2016/05/17 19:35:45, Dan Beam wrote:
> why do you want to run both indexOf() and the loop below?  isn't the code
> duplicative?  it probably doesn't matter for general performance, just
wondering
> why we need the extra search.

like the comment says: 99.99% of the time indexOf will work and we'll return, so
why do all the math below?

that said... i think i can address both your comments at the same time, sort of.

https://codereview.chromium.org/1967913002/diff/120001/ui/webui/resources/cr_...
File ui/webui/resources/cr_elements/cr_slider/cr_slider.js (right):

https://codereview.chromium.org/1967913002/diff/120001/ui/webui/resources/cr_...
ui/webui/resources/cr_elements/cr_slider/cr_slider.js:78: // The pref changed
somewhere else (e.g., sync) but we're still holding
On 2016/05/18 00:58:41, dschuyler wrote:
> Since this is outside of settings and doesn't rely on 
> prefs otherwise, consider changing this comment (so it
> doesn't mention pref). e.g. the value changed...

Good point, thanks.

https://codereview.chromium.org/1967913002/diff/140001/ui/webui/resources/cr_...
File ui/webui/resources/cr_elements/cr_slider/cr_slider.js (right):

https://codereview.chromium.org/1967913002/diff/140001/ui/webui/resources/cr_...
ui/webui/resources/cr_elements/cr_slider/cr_slider.js:103: assert(typeof
closestIndex != 'undefined');
basically asserts the same thing, but closure-friendly

[dschuyler, 2016-05-18 20:51:21]

LGTM with optional nits.

https://codereview.chromium.org/1967913002/diff/160001/chrome/browser/resourc...
File
chrome/browser/resources/settings/appearance_page/appearance_fonts_page.html
(right):

https://codereview.chromium.org/1967913002/diff/160001/chrome/browser/resourc...
chrome/browser/resources/settings/appearance_page/appearance_fonts_page.html:49:
no whitespace -->: $i18n{quickBrownFox}
nit:
will this work instead:

  <span>
    <span>[[prefs.webkit.webprefs.default_font_size.value]</span>
    : $i18n{quickBrownFox}
  </span>

Of if the nbsp is preferred:

  <span>[[prefs.webkit.webprefs.default_font_size.value]</span>
  :&nbsp;
  $i18n{quickBrownFox}

The goal being a space following the colon (rather than "The quick..."
text being immediately after the colon).

https://codereview.chromium.org/1967913002/diff/160001/ui/webui/resources/cr_...
File ui/webui/resources/cr_elements/cr_slider/cr_slider.js (right):

https://codereview.chromium.org/1967913002/diff/160001/ui/webui/resources/cr_...
ui/webui/resources/cr_elements/cr_slider/cr_slider.js:36: },
nit: Can this be 

snaps: Boolean,

[michaelpg, 2016-05-19 17:09:27]

https://codereview.chromium.org/1967913002/diff/160001/chrome/browser/resourc...
File
chrome/browser/resources/settings/appearance_page/appearance_fonts_page.html
(right):

https://codereview.chromium.org/1967913002/diff/160001/chrome/browser/resourc...
chrome/browser/resources/settings/appearance_page/appearance_fonts_page.html:49:
no whitespace -->: $i18n{quickBrownFox}
On 2016/05/18 20:51:21, dschuyler wrote:
> nit:
> will this work instead:
> 
>   <span>
>     <span>[[prefs.webkit.webprefs.default_font_size.value]</span>
>     : $i18n{quickBrownFox}
>   </span>
> 
> Of if the nbsp is preferred:
> 
>   <span>[[prefs.webkit.webprefs.default_font_size.value]</span>
>   :&nbsp;
>   $i18n{quickBrownFox}
> 
> The goal being a space following the colon (rather than "The quick..."
> text being immediately after the colon).

Done. I also filed https://crbug.com/id=613203 because this looks weird with and
without my patch.

https://codereview.chromium.org/1967913002/diff/160001/ui/webui/resources/cr_...
File ui/webui/resources/cr_elements/cr_slider/cr_slider.js (right):

https://codereview.chromium.org/1967913002/diff/160001/ui/webui/resources/cr_...
ui/webui/resources/cr_elements/cr_slider/cr_slider.js:36: },
On 2016/05/18 20:51:21, dschuyler wrote:
> nit: Can this be 
> 
> snaps: Boolean,
> 

nope:
https://www.polymer-project.org/1.0/docs/devguide/properties#configuring-bool...

[Dan Beam, 2016-05-24 01:54:49]

i didn't really re-review everything but cr_slider.js looks fine and you already
got enough reviews ;) so lgtm

[michaelpg, 2016-05-26 17:59:36]

The CQ bit was checked by michaelpg@chromium.org

[michaelpg, 2016-05-26 17:59:37]

The patchset sent to the CQ was uploaded after l-g-t-m from
stevenjb@chromium.org, dschuyler@chromium.org, dbeam@chromium.org
Link to the patchset: https://codereview.chromium.org/1967913002/#ps200001
(title: "rebase")

[commit-bot: I haz the power, 2016-05-26 17:59:59]

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

[commit-bot: I haz the power, 2016-05-26 18:37:40]

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

[commit-bot: I haz the power, 2016-05-26 18:37:42]

Try jobs failed on following builders:
  linux_chromium_chromeos_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[michaelpg, 2016-05-27 15:49:50]

Patchset #11 (id:220001) has been deleted

[michaelpg, 2016-05-27 15:51:31]

The CQ bit was checked by michaelpg@chromium.org

[michaelpg, 2016-05-27 15:51:31]

The patchset sent to the CQ was uploaded after l-g-t-m from
dschuyler@chromium.org, stevenjb@chromium.org, dbeam@chromium.org
Link to the patchset: https://codereview.chromium.org/1967913002/#ps240001
(title: "rebase")

[commit-bot: I haz the power, 2016-05-27 15:51:52]

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

[commit-bot: I haz the power, 2016-05-27 16:27:32]

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

[commit-bot: I haz the power, 2016-05-27 16:27:34]

Try jobs failed on following builders:
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[michaelpg, 2016-05-27 19:23:06]

michaelpg@chromium.org changed reviewers:
+ tsergeant@chromium.org

[michaelpg, 2016-05-27 19:23:08]

+tsergeant for FYI after expanding cr_elements_browsertest.js.

https://codereview.chromium.org/1967913002/diff/260001/chrome/test/data/webui...
File chrome/test/data/webui/cr_elements/cr_toolbar_search_field_tests.js
(right):

https://codereview.chromium.org/1967913002/diff/260001/chrome/test/data/webui...
chrome/test/data/webui/cr_elements/cr_toolbar_search_field_tests.js:8:
suite('cr-toolbar-search-field', function() {
rietveld sucks but everything below here is just a straight copy with an extra
indent

[michaelpg, 2016-05-27 19:23:32]

The CQ bit was checked by michaelpg@chromium.org

[michaelpg, 2016-05-27 19:23:33]

The patchset sent to the CQ was uploaded after l-g-t-m from
dschuyler@chromium.org, stevenjb@chromium.org, dbeam@chromium.org
Link to the patchset: https://codereview.chromium.org/1967913002/#ps260001
(title: "Merge cr-elements tests")

[commit-bot: I haz the power, 2016-05-27 19:24:13]

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

[commit-bot: I haz the power, 2016-05-27 19:27:17]

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

[commit-bot: I haz the power, 2016-05-27 19:27:19]

Try jobs failed on following builders:
  ios-device on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-simulator on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
  mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_gn_rel on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_gn_r...)
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[michaelpg, 2016-06-02 18:27:38]

The CQ bit was checked by michaelpg@chromium.org

[michaelpg, 2016-06-02 18:27:39]

The patchset sent to the CQ was uploaded after l-g-t-m from
dschuyler@chromium.org, stevenjb@chromium.org, dbeam@chromium.org
Link to the patchset: https://codereview.chromium.org/1967913002/#ps300001
(title: "rebase fix")

[commit-bot: I haz the power, 2016-06-02 18:28:23]

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

[commit-bot: I haz the power, 2016-06-02 21:43:41]

Description was changed from

==========
Material WebUI: cr-slider element for intelligent range mapping

Most sliders don't correspond 1:1 with a range of values. For instance,
we curate a range of valid values for pointer sensitivity, then map these
to a linear slider.

<cr-slider> takes an array of values corresponding to slider indices, and
binds the value of the <paper-slider> it wraps to the host element's property.

This simplifies the logic that was duplicated in keyboard.html and
appearance_fonts_page.html. It also fixes a rare edge case when a pref value
updates while the slider is being dragged.

BUG=611949
TEST=CrElementsBrowserTest.CrElements
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

to

==========
Material WebUI: cr-slider element for intelligent range mapping

Most sliders don't correspond 1:1 with a range of values. For instance,
we curate a range of valid values for pointer sensitivity, then map these
to a linear slider.

<cr-slider> takes an array of values corresponding to slider indices, and
binds the value of the <paper-slider> it wraps to the host element's property.

This simplifies the logic that was duplicated in keyboard.html and
appearance_fonts_page.html. It also fixes a rare edge case when a pref value
updates while the slider is being dragged.

BUG=611949
TEST=CrElementsBrowserTest.CrElements
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

[commit-bot: I haz the power, 2016-06-02 21:43:43]

Committed patchset #14 (id:300001)

[commit-bot: I haz the power, 2016-06-02 21:46:53]

Description was changed from

==========
Material WebUI: cr-slider element for intelligent range mapping

Most sliders don't correspond 1:1 with a range of values. For instance,
we curate a range of valid values for pointer sensitivity, then map these
to a linear slider.

<cr-slider> takes an array of values corresponding to slider indices, and
binds the value of the <paper-slider> it wraps to the host element's property.

This simplifies the logic that was duplicated in keyboard.html and
appearance_fonts_page.html. It also fixes a rare edge case when a pref value
updates while the slider is being dragged.

BUG=611949
TEST=CrElementsBrowserTest.CrElements
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation
==========

to

==========
Material WebUI: cr-slider element for intelligent range mapping

Most sliders don't correspond 1:1 with a range of values. For instance,
we curate a range of valid values for pointer sensitivity, then map these
to a linear slider.

<cr-slider> takes an array of values corresponding to slider indices, and
binds the value of the <paper-slider> it wraps to the host element's property.

This simplifies the logic that was duplicated in keyboard.html and
appearance_fonts_page.html. It also fixes a rare edge case when a pref value
updates while the slider is being dragged.

BUG=611949
TEST=CrElementsBrowserTest.CrElements
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation

Committed: https://crrev.com/d326605487da452867181c1fe0dc7c6580b0d714
Cr-Commit-Position: refs/heads/master@{#397517}
==========

[commit-bot: I haz the power, 2016-06-02 21:46:55]

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