Handle cases where selection API doesn't apply #19461

jonleighton · 2017-12-02T10:04:46Z

The selection API only applies to certain types:

https://html.spec.whatwg.org/multipage/#do-not-apply

This commit ensures that we handle that correctly.

Some notes:

TextControl::set_dom_selection_direction now calls
set_selection_range(), which means that setting selectionDirection will
now fire a selection event, as it should per the spec.
There is a test for the firing of the select event in
tests/wpt/web-platform-tests/html/semantics/forms/textfieldselection/select-event.html,
however the test did not run due to this syntax error:

(pid:26017) "ERROR:script::dom::bindings::error: Error at http://web-platform.test:8000/html/semantics/forms/textfieldselection/select-event.html:50:11 missing = in const declaration"

This happens due to the us of the "for (const foo of ...)" construct.
Per https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...of
this should actually work, so it's somewhat unsatisfying to have to
change the test.
I removed tests/wpt/web-platform-tests/html/semantics/forms/textfieldselection/selection-not-application-textarea.html
because it doesn't seem to add any extra value - the selection API
always applies to textarea elements, and the API is tested elsewhere.
If an <input>'s type is unset, it defaults to a text, and the
selection API applies. Also, if an <input>'s type is set to an
invalid value, it defaults to a text too. This second case doesn't
currently work, and I'll need to do more restructuring of the code in
a future commit. See discussion with nox in IRC:
https://mozilla.logbot.info/servo/20171201#c13946454-c13946594

This change is

highfive · 2017-12-02T10:04:51Z

Heads up! This PR modifies the following files:

@asajeffrey: components/script/dom/htmltextareaelement.rs, components/script/dom/textcontrol.rs, components/script/dom/webidls/HTMLInputElement.webidl, components/script/dom/webidls/HTMLTextAreaElement.webidl, components/script/dom/htmlinputelement.rs and 1 more
@fitzgen: components/script/dom/htmltextareaelement.rs, components/script/dom/textcontrol.rs, components/script/dom/webidls/HTMLInputElement.webidl, components/script/dom/webidls/HTMLTextAreaElement.webidl, components/script/dom/htmlinputelement.rs and 1 more
@KiChjang: components/script/dom/htmltextareaelement.rs, components/script/dom/textcontrol.rs, components/script/dom/webidls/HTMLInputElement.webidl, components/script/dom/webidls/HTMLTextAreaElement.webidl, components/script/dom/htmlinputelement.rs and 1 more

nox · 2017-12-02T14:01:54Z

Please remove my name from the commit message, I get a notification every time it's pushed on GH (just make it nox instead of @nox to fix that issue).

jonleighton · 2017-12-02T19:25:50Z

Sorry about that, done. Do you want to still be assigned? Not sure if you want to be involved with this, @KiChjang has reviewed several of my previous patches but this obviously relates somewhat to what we discussed in IRC.

(Also not sure if you got assigned because I mentioned you or whether it was just luck of the draw, I don't really know how the bot works, but anyway, feel free to tell me what you prefer.)

This came out of a conversation with nox in IRC: https://mozilla.logbot.info/servo/20171201#c13946454-c13946594 The code I was working on which motivated this change is here: servo#19461 Previously, InputType::Text was used to represent several different values of the type attribute on an input element. If an input element doesn't have a type attribute, or its type attribute doesn't contain a recognised value, then the input's type defaults to "text". Before this change, there were a number of checks in the code which directly looked at the type attribute. If those checks matched against the value "text", then they were potentially buggy, since an input with type=invalid should also behave like an input with type=text. Rather than have every conditional which cares about the input type also have to deal with invalid input types, we can convert the type attribute to an InputType enum once, and then match against the enum. A secondary benefit is that the compiler can tell us whether we've missed branches in a match expression. While working on this I discovered that the HTMLInputElement::value_mode() method misses a case for inputs with type=hidden (this resulted in a failing WPT test passing). I've also implemented the Default trait for InputType, so we now only have one place in the code which knows that InputType::Text is the default, where previously there were several.

jonleighton · 2017-12-03T20:17:14Z

I've now submitted #19471 which cleans up the handling of the type attribute. If that gets merged, I can make this change a bit cleaner and the tests for <input type=invalidvalue> will pass.

This came out of a conversation with nox in IRC: https://mozilla.logbot.info/servo/20171201#c13946454-c13946594 The code I was working on which motivated this change is here: servo#19461 Previously, InputType::Text was used to represent several different values of the type attribute on an input element. If an input element doesn't have a type attribute, or its type attribute doesn't contain a recognised value, then the input's type defaults to "text". Before this change, there were a number of checks in the code which directly looked at the type attribute. If those checks matched against the value "text", then they were potentially buggy, since an input with type=invalid should also behave like an input with type=text. Rather than have every conditional which cares about the input type also have to deal with invalid input types, we can convert the type attribute to an InputType enum once, and then match against the enum. A secondary benefit is that the compiler can tell us whether we've missed branches in a match expression. While working on this I discovered that the HTMLInputElement::value_mode() method misses a case for inputs with type=hidden (this resulted in a failing WPT test passing). I've also implemented the Default trait for InputType, so we now only have one place in the code which knows that InputType::Text is the default, where previously there were several.

Expand InputType to cover all possible types This came out of a conversation with nox in IRC: https://mozilla.logbot.info/servo/20171201#c13946454-c13946594 The code I was working on which motivated this change is here: #19461 Previously, InputType::Text was used to represent several different values of the type attribute on an input element. If an input element doesn't have a type attribute, or its type attribute doesn't contain a recognised value, then the input's type defaults to "text". Before this change, there were a number of checks in the code which directly looked at the type attribute. If those checks matched against the value "text", then they were potentially buggy, since an input with type=invalid should also behave like an input with type=text. Rather than have every conditional which cares about the input type also have to deal with invalid input types, we can convert the type attribute to an InputType enum once, and then match against the enum. A secondary benefit is that the compiler can tell us whether we've missed branches in a match expression. While working on this I discovered that the HTMLInputElement::value_mode() method misses a case for inputs with type=hidden (this resulted in a failing WPT test passing). I've also implemented the Default trait for InputType, so we now only have one place in the code which knows that InputType::Text is the default, where previously there were several.  --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/19471)

This came out of a conversation with nox in IRC: https://mozilla.logbot.info/servo/20171201#c13946454-c13946594 The code I was working on which motivated this change is here: servo#19461 Previously, InputType::Text was used to represent several different values of the type attribute on an input element. If an input element doesn't have a type attribute, or its type attribute doesn't contain a recognised value, then the input's type defaults to "text". Before this change, there were a number of checks in the code which directly looked at the type attribute. If those checks matched against the value "text", then they were potentially buggy, since an input with type=invalid should also behave like an input with type=text. Rather than have every conditional which cares about the input type also have to deal with invalid input types, we can convert the type attribute to an InputType enum once, and then match against the enum. A secondary benefit is that the compiler can tell us whether we've missed branches in a match expression. While working on this I discovered that the HTMLInputElement::value_mode() method misses a case for inputs with type=hidden (this resulted in a failing WPT test passing). I've also implemented the Default trait for InputType, so we now only have one place in the code which knows that InputType::Text is the default, where previously there were several.

Expand InputType to cover all possible types This came out of a conversation with nox in IRC: https://mozilla.logbot.info/servo/20171201#c13946454-c13946594 The code I was working on which motivated this change is here: #19461 Previously, InputType::Text was used to represent several different values of the type attribute on an input element. If an input element doesn't have a type attribute, or its type attribute doesn't contain a recognised value, then the input's type defaults to "text". Before this change, there were a number of checks in the code which directly looked at the type attribute. If those checks matched against the value "text", then they were potentially buggy, since an input with type=invalid should also behave like an input with type=text. Rather than have every conditional which cares about the input type also have to deal with invalid input types, we can convert the type attribute to an InputType enum once, and then match against the enum. A secondary benefit is that the compiler can tell us whether we've missed branches in a match expression. While working on this I discovered that the HTMLInputElement::value_mode() method misses a case for inputs with type=hidden (this resulted in a failing WPT test passing). I've also implemented the Default trait for InputType, so we now only have one place in the code which knows that InputType::Text is the default, where previously there were several.  --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/19471)

…rom jonleighton:input-type); r=jdm This came out of a conversation with nox in IRC: https://mozilla.logbot.info/servo/20171201#c13946454-c13946594 The code I was working on which motivated this change is here: servo/servo#19461 Previously, InputType::Text was used to represent several different values of the type attribute on an input element. If an input element doesn't have a type attribute, or its type attribute doesn't contain a recognised value, then the input's type defaults to "text". Before this change, there were a number of checks in the code which directly looked at the type attribute. If those checks matched against the value "text", then they were potentially buggy, since an input with type=invalid should also behave like an input with type=text. Rather than have every conditional which cares about the input type also have to deal with invalid input types, we can convert the type attribute to an InputType enum once, and then match against the enum. A secondary benefit is that the compiler can tell us whether we've missed branches in a match expression. While working on this I discovered that the HTMLInputElement::value_mode() method misses a case for inputs with type=hidden (this resulted in a failing WPT test passing). I've also implemented the Default trait for InputType, so we now only have one place in the code which knows that InputType::Text is the default, where previously there were several. Source-Repo: https://github.com/servo/servo Source-Revision: 6a6da9c2a4805d28365961c6ecd1e8dc7559b0b1 --HG-- extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear extra : subtree_revision : f18c1efa8e5697d9338a1ee65c1ac855537bdd5f

jonleighton · 2017-12-07T11:35:24Z

r? @KiChjang

…rom jonleighton:input-type); r=jdm This came out of a conversation with nox in IRC: https://mozilla.logbot.info/servo/20171201#c13946454-c13946594 The code I was working on which motivated this change is here: servo/servo#19461 Previously, InputType::Text was used to represent several different values of the type attribute on an input element. If an input element doesn't have a type attribute, or its type attribute doesn't contain a recognised value, then the input's type defaults to "text". Before this change, there were a number of checks in the code which directly looked at the type attribute. If those checks matched against the value "text", then they were potentially buggy, since an input with type=invalid should also behave like an input with type=text. Rather than have every conditional which cares about the input type also have to deal with invalid input types, we can convert the type attribute to an InputType enum once, and then match against the enum. A secondary benefit is that the compiler can tell us whether we've missed branches in a match expression. While working on this I discovered that the HTMLInputElement::value_mode() method misses a case for inputs with type=hidden (this resulted in a failing WPT test passing). I've also implemented the Default trait for InputType, so we now only have one place in the code which knows that InputType::Text is the default, where previously there were several. Source-Repo: https://github.com/servo/servo Source-Revision: 6a6da9c2a4805d28365961c6ecd1e8dc7559b0b1

KiChjang

Great work! I don't see much problems with the code, but I have some comments about the tests.

KiChjang · 2017-12-07T21:23:40Z

components/script/dom/htmlinputelement.rs

@@ -408,6 +408,17 @@ impl TextControl for HTMLInputElement {
    fn textinput(&self) -> &DomRefCell<TextInput<ScriptToConstellationChan>> {
        &self.textinput
    }
+
+    fn selection_api_applies(&self) -> bool {


Can you link to the relevant section of the spec that defines this behaviour?

KiChjang · 2017-12-07T21:24:10Z

tests/wpt/metadata/html/semantics/forms/textfieldselection/select-event.html.ini

+
+  [input type password: setRangeText()]
+    expected: FAIL
+


Why are there so many expected test failures?

These are just things that haven't yet been implemented:

select() method

setRangeText() method

Code to avoid firing the select event when the selection hasn't actually moved

KiChjang · 2017-12-07T21:24:56Z

tests/wpt/web-platform-tests/html/semantics/forms/textfieldselection/select-event.html

  const elLabel = el.localName === "textarea" ? "textarea" : "input type " + el.type;

-  for (const action of actions) {
+  actions.forEach((action) => {


Why the change?

This is explained in the commit message:

There is a test for the firing of the select event in
tests/wpt/web-platform-tests/html/semantics/forms/textfieldselection/select-event.html,
however the test did not run due to this syntax error:

(pid:26017) "ERROR:script::dom::bindings::error: Error at http://web-platform.test:8000/html/semantics/forms/textfieldselection/select-event.html:50:11 missing = in const declaration"

This happens due to the us of the "for (const foo of ...)" construct.
Per https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...of
this should actually work, so it's somewhat unsatisfying to have to
change the test.

Definitely not ideal to have to change this, so I'm open to other suggestions! But without changing this, the changes here are not fully tested (specifically, setting selectionDirection will now call set_selection_range and fire the select event, and this test file verifies that behaviour).

Does let instead of const work? If not, then this looks like it's a problem with our implementation, and not the tests. To reiterate: these tests are shared across all other browsers, so we cannot simply change the tests as we like to make it pass.

Our spidermonkey version doesn't support for (const foo of bar). We modify tests to use for (let foo of bar) instead when we want to be able to run them.

I think I tried let but was having trouble for some reason. I'll have another go.

Or maybe put the modified version in tests/wpt/mozilla/ for the time being? Seems a shame not to have it tested in any way, as then we won't be sure we're not introducing regressions.

Though as far as I can see those tests (in tests/wpt/mozilla/) don't actually get run by the CI? So maybe that wouldn't particularly help.

No, tests/wpt/mozilla/ definitely get run by CI. Adding a modified version to that directory is a good idea.

15:24 <annevk> nox: I think it’s considered acceptable to rewrite if not too much of a concession in readability

We could just use the forEach method in that test.

@jdm are you happy to do as @nox suggests (if so, this can be merged as it is), or shall I add the modified test in tests/wpt/mozilla?

KiChjang · 2017-12-07T21:25:25Z

...atform-tests/html/semantics/forms/textfieldselection/selection-not-application-textarea.html

@@ -1,29 +0,0 @@
-<!DOCTYPE html>


Why is this test file removed?

Also explained in the commit message:

I removed tests/wpt/web-platform-tests/html/semantics/forms/textfieldselection/selection-not-application-textarea.html
because it doesn't seem to add any extra value - the selection API
always applies to textarea elements, and the API is tested elsewhere.

I'd rather not remove this haphazardly without contacting the authors or upstream W3C about this. Note that this is not a servo-specific test - any changes you make under tests/wpt/web-platform-tests are shared across all browsers.

Fair enough, I'll reinstate it.

The selection API only applies to certain <input> types: https://html.spec.whatwg.org/multipage/#do-not-apply This commit ensures that we handle that correctly. Some notes: 1. TextControl::set_dom_selection_direction now calls set_selection_range(), which means that setting selectionDirection will now fire a selection event, as it should per the spec. 2. There is a test for the firing of the select event in tests/wpt/web-platform-tests/html/semantics/forms/textfieldselection/select-event.html, however the test did not run due to this syntax error: (pid:26017) "ERROR:script::dom::bindings::error: Error at http://web-platform.test:8000/html/semantics/forms/textfieldselection/select-event.html:50:11 missing = in const declaration" This happens due to the us of the "for (const foo of ...)" construct. Per https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...of this should actually work, so it's somewhat unsatisfying to have to change the test. 4. If an <input>'s type is unset, it defaults to a text, and the selection API applies. Also, if an <input>'s type is set to an invalid value, it defaults to a text too. I've expanded the tests to account for this second case.

KiChjang · 2017-12-08T21:46:48Z

...pt/web-platform-tests/html/semantics/forms/textfieldselection/selection-not-application.html

-  var types = ["hidden", "email", "datetime-local", "date", "month", "week", "time", "number", "range", "color", "checkbox", "radio", "file", "submit", "image", "reset", "button"]; //types for which the API doesn't apply
-  var types2 = ["text", "search", "tel", "url", "password"]; //types for which the API applies
+  var nonApplicableTypes = ["hidden", "email", "datetime-local", "date", "month", "week", "time", "number", "range", "color", "checkbox", "radio", "file", "submit", "image", "reset", "button"];
+  var applicableTypes = ["text", "search", "tel", "url", "password", "aninvalidtype", null];


Why are null and "aninvalidtype" accepted? Is it because they're both going to be treated as "text"?

Correct. My first implementation only worked with the former, but now since I've done the InputType refactoring, both are correctly treated as "text".

KiChjang · 2017-12-11T00:37:55Z

@jonleighton This should be good enough; thanks for your work!

@bors-servo r+

bors-servo · 2017-12-11T00:37:56Z

📌 Commit 71a013d has been approved by KiChjang

bors-servo · 2017-12-11T00:38:00Z

⌛ Testing commit 71a013d with merge db41cc0...

Handle cases where selection API doesn't apply The selection API only applies to certain <input> types: https://html.spec.whatwg.org/multipage/#do-not-apply This commit ensures that we handle that correctly. Some notes: 1. TextControl::set_dom_selection_direction now calls set_selection_range(), which means that setting selectionDirection will now fire a selection event, as it should per the spec. 2. There is a test for the firing of the select event in tests/wpt/web-platform-tests/html/semantics/forms/textfieldselection/select-event.html, however the test did not run due to this syntax error: (pid:26017) "ERROR:script::dom::bindings::error: Error at http://web-platform.test:8000/html/semantics/forms/textfieldselection/select-event.html:50:11 missing = in const declaration" This happens due to the us of the "for (const foo of ...)" construct. Per https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...of this should actually work, so it's somewhat unsatisfying to have to change the test. 3. I removed tests/wpt/web-platform-tests/html/semantics/forms/textfieldselection/selection-not-application-textarea.html because it doesn't seem to add any extra value - the selection API always applies to textarea elements, and the API is tested elsewhere. 4. If an `<input>`'s type is unset, it defaults to a text, and the selection API applies. Also, if an `<input>`'s type is set to an invalid value, it defaults to a text too. This second case doesn't currently work, and I'll need to do more restructuring of the code in a future commit. See discussion with nox in IRC: https://mozilla.logbot.info/servo/20171201#c13946454-c13946594  --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/19461)

bors-servo · 2017-12-11T02:01:56Z

☀️ Test successful - android, arm32, arm64, linux-dev, linux-rel-css, linux-rel-wpt, mac-dev-unit, mac-rel-css1, mac-rel-css2, mac-rel-wpt1, mac-rel-wpt2, mac-rel-wpt3, mac-rel-wpt4, windows-msvc-dev
Approved by: KiChjang
Pushing db41cc0 to master...

jonleighton · 2017-12-11T08:08:34Z

Hooray, thanks ✨

…rom jonleighton:input-type); r=jdm This came out of a conversation with nox in IRC: https://mozilla.logbot.info/servo/20171201#c13946454-c13946594 The code I was working on which motivated this change is here: servo/servo#19461 Previously, InputType::Text was used to represent several different values of the type attribute on an input element. If an input element doesn't have a type attribute, or its type attribute doesn't contain a recognised value, then the input's type defaults to "text". Before this change, there were a number of checks in the code which directly looked at the type attribute. If those checks matched against the value "text", then they were potentially buggy, since an input with type=invalid should also behave like an input with type=text. Rather than have every conditional which cares about the input type also have to deal with invalid input types, we can convert the type attribute to an InputType enum once, and then match against the enum. A secondary benefit is that the compiler can tell us whether we've missed branches in a match expression. While working on this I discovered that the HTMLInputElement::value_mode() method misses a case for inputs with type=hidden (this resulted in a failing WPT test passing). I've also implemented the Default trait for InputType, so we now only have one place in the code which knows that InputType::Text is the default, where previously there were several. Source-Repo: https://github.com/servo/servo Source-Revision: 6a6da9c2a4805d28365961c6ecd1e8dc7559b0b1

The selection API only applies to certain <input> types: https://html.spec.whatwg.org/multipage/#do-not-apply This commit ensures that we handle that correctly. Some notes: 1. TextControl::set_dom_selection_direction now calls set_selection_range(), which means that setting selectionDirection will now fire a selection event, as it should per the spec. 2. There is a test for the firing of the select event in tests/wpt/web-platform-tests/html/semantics/forms/textfieldselection/select-event.html, however the test did not run due to this syntax error: (pid:26017) "ERROR:script::dom::bindings::error: Error at http://web-platform.test:8000/html/semantics/forms/textfieldselection/select-event.html:50:11 missing = in const declaration" This happens due to the us of the "for (const foo of ...)" construct. Per https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...of this should actually work, so it's somewhat unsatisfying to have to change the test. 4. If an <input>'s type is unset, it defaults to a text, and the selection API applies. Also, if an <input>'s type is set to an invalid value, it defaults to a text too. I've expanded the tests to account for this second case. Upstreamed from servo/servo#19461 [ci skip]

…rom jonleighton:input-type); r=jdm This came out of a conversation with nox in IRC: https://mozilla.logbot.info/servo/20171201#c13946454-c13946594 The code I was working on which motivated this change is here: servo/servo#19461 Previously, InputType::Text was used to represent several different values of the type attribute on an input element. If an input element doesn't have a type attribute, or its type attribute doesn't contain a recognised value, then the input's type defaults to "text". Before this change, there were a number of checks in the code which directly looked at the type attribute. If those checks matched against the value "text", then they were potentially buggy, since an input with type=invalid should also behave like an input with type=text. Rather than have every conditional which cares about the input type also have to deal with invalid input types, we can convert the type attribute to an InputType enum once, and then match against the enum. A secondary benefit is that the compiler can tell us whether we've missed branches in a match expression. While working on this I discovered that the HTMLInputElement::value_mode() method misses a case for inputs with type=hidden (this resulted in a failing WPT test passing). I've also implemented the Default trait for InputType, so we now only have one place in the code which knows that InputType::Text is the default, where previously there were several. Source-Repo: https://github.com/servo/servo Source-Revision: 6a6da9c2a4805d28365961c6ecd1e8dc7559b0b1 UltraBlame original commit: 037bb8f0387317bd0763d9bbf91a16e8300f4aef

highfive assigned nox Dec 2, 2017

highfive added the S-awaiting-review There is new code that needs to be reviewed. label Dec 2, 2017

jonleighton force-pushed the issue-19171-4 branch from 6688224 to b9377ec Compare December 2, 2017 19:24

This was referenced Dec 3, 2017

Expand InputType to cover all possible types #19471

Merged

Text control selections API conformance #19171

Closed

jonleighton force-pushed the issue-19171-4 branch from b9377ec to a3da184 Compare December 7, 2017 11:29

highfive assigned KiChjang and unassigned nox Dec 7, 2017

KiChjang reviewed Dec 7, 2017

View reviewed changes

KiChjang added S-awaiting-answer Someone asked a question that requires an answer. and removed S-awaiting-review There is new code that needs to be reviewed. labels Dec 7, 2017

jonleighton force-pushed the issue-19171-4 branch from a3da184 to b75b939 Compare December 8, 2017 17:17

highfive added the S-awaiting-review There is new code that needs to be reviewed. label Dec 8, 2017

jonleighton force-pushed the issue-19171-4 branch from b75b939 to 71a013d Compare December 8, 2017 20:07

KiChjang reviewed Dec 8, 2017

View reviewed changes

highfive added S-awaiting-merge The PR is in the process of compiling and running tests on the automated CI. and removed S-awaiting-review There is new code that needs to be reviewed. S-awaiting-answer Someone asked a question that requires an answer. labels Dec 11, 2017

bors-servo merged commit 71a013d into servo:master Dec 11, 2017

highfive removed the S-awaiting-merge The PR is in the process of compiling and running tests on the automated CI. label Dec 11, 2017

servo-wpt-sync mentioned this pull request Jan 4, 2018

Handle cases where selection API doesn't apply web-platform-tests/wpt#8914

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Handle cases where selection API doesn't apply #19461

Handle cases where selection API doesn't apply #19461

jonleighton commented Dec 2, 2017 •

edited by jdm

highfive commented Dec 2, 2017

nox commented Dec 2, 2017 •

edited

jonleighton commented Dec 2, 2017

jonleighton commented Dec 3, 2017

jonleighton commented Dec 7, 2017

KiChjang left a comment

KiChjang Dec 7, 2017

jonleighton Dec 8, 2017

KiChjang Dec 7, 2017

jonleighton Dec 8, 2017

KiChjang Dec 7, 2017

jonleighton Dec 8, 2017

KiChjang Dec 8, 2017 •

edited

jdm Dec 8, 2017

jonleighton Dec 8, 2017

jonleighton Dec 9, 2017

jonleighton Dec 9, 2017

jdm Dec 10, 2017

nox Dec 10, 2017

jonleighton Dec 10, 2017

KiChjang Dec 7, 2017

jonleighton Dec 8, 2017

KiChjang Dec 8, 2017

jonleighton Dec 8, 2017

KiChjang Dec 8, 2017

jonleighton Dec 9, 2017

KiChjang commented Dec 11, 2017

bors-servo commented Dec 11, 2017

bors-servo commented Dec 11, 2017

bors-servo commented Dec 11, 2017

jonleighton commented Dec 11, 2017

Handle cases where selection API doesn't apply #19461

Handle cases where selection API doesn't apply #19461

Conversation

jonleighton commented Dec 2, 2017 • edited by jdm

highfive commented Dec 2, 2017

nox commented Dec 2, 2017 • edited

jonleighton commented Dec 2, 2017

jonleighton commented Dec 3, 2017

jonleighton commented Dec 7, 2017

KiChjang left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

KiChjang Dec 8, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

KiChjang commented Dec 11, 2017

bors-servo commented Dec 11, 2017

bors-servo commented Dec 11, 2017

bors-servo commented Dec 11, 2017

jonleighton commented Dec 11, 2017

jonleighton commented Dec 2, 2017 •

edited by jdm

nox commented Dec 2, 2017 •

edited

KiChjang Dec 8, 2017 •

edited