Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement range input sanitization #21952

Closed
wants to merge 3 commits into from
Closed

Conversation

Eijebong
Copy link
Contributor

@Eijebong Eijebong commented Oct 15, 2018

This change is Reviewable

It was setting the value to " 123" without setting a maximum above.
Since the specs specifies 100 to be the default max, the value we'd get
after sanitization would be 100, not 123. This fixes it by setting the
value to something that is between the default min/max.
@highfive
Copy link

Heads up! This PR modifies the following files:

  • @asajeffrey: components/script/dom/element.rs, components/script/dom/bindings/htmlconstructor.rs, components/script/dom/servoparser/mod.rs, components/script/dom/htmlinputelement.rs
  • @KiChjang: components/script/dom/element.rs, components/script/dom/bindings/htmlconstructor.rs, components/script/dom/servoparser/mod.rs, components/script/dom/htmlinputelement.rs

@highfive highfive added the S-awaiting-review There is new code that needs to be reviewed. label Oct 15, 2018
@servo-wpt-sync
Copy link
Collaborator

Opened new PR for upstreamable changes.

Completed upstream sync of web-platform-test changes at web-platform-tests/wpt#13529.

Copy link
Contributor

@nox nox left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First initial review.

@@ -166,6 +166,8 @@ where
// Step 8.4
element.set_custom_element_definition(definition.clone());

element.done_creating();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to have become substeps of step 9, could you renumber the steps and add a todo for the now missing part?

pub fn done_creating(&self) {
self.done_creating.set(true);
if let Some(el) = self.downcast::<HTMLInputElement>() {
el.refresh_value(el.Value());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we avoid passing the element's own value to refresh_value? This seems like that involves cloning the value for no reason.

// https://html.spec.whatwg.org/multipage/#value-sanitization-algorithm
fn sanitize_value(&self, value: &mut DOMString) {
let el = self.upcast::<Element>();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: no need for intermediate binding here.


// Step 8.
for attr in attrs {
element.set_attribute_from_parser(attr.name, attr.value, None);
}

element.done_creating();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this somewhere in the spec btw?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so but without that the input was revalidating it's input when we set value (with a default min/max), then for min then for max and it was causing troubles. For example, setting no value would set it to 50, then setting a min to 2, a max to 6 would set the value to 6 since 50 > 6 instead of setting it to 4.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The same thing has happened to me taking an independent attempt at getting min/max/step working; I'm going to pick up this approach and run with it.

@@ -1193,7 +1193,47 @@ impl HTMLInputElement {
},
// https://html.spec.whatwg.org/multipage/#range-state-(type=range):value-sanitization-algorithm
InputType::Range => {
value.set_best_representation_of_the_floating_point_number();
let minimum = self.Min().parse().unwrap_or(0f64);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be nice to not directly go through the IDL getters to avoid a DOMString copy. AFAIK min, max and step attribute values should be stored as integers in HTMLInputElement, feel free to ping me on IRC if you need more details about that.

value
}
} else {
if maximum <= minimum {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be just <.

maximum
} else {
value
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this can be a shorter expression:

value.min(maximum).max(minimum)

Clamping by the maximum before the minimum covers the case where the former is less than the latter.

}
} else {
new_v
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note to self: I haven't reviewed this yet.

@jdm jdm assigned nox and unassigned avadacatavra Oct 16, 2018
@@ -34,7 +34,7 @@ <h1>Input Range</h1>
<input type="range" id="stepdown_beyond_min" min=3 max=11 value=6 step=3 />
<input type="range" id="illegal_min_and_max" min="ab" max="f" />
<input type="range" id="illegal_value_and_step" min=0 max=5 value="ppp" step="xyz" />
<input type="range" id="should_skip_whitespace" value=" 123"/>
<input type="range" id="should_skip_whitespace" value=" 98"/>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why use 98 rather than 123?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because 123 is outside the default min-max range (0-100)

@bors-servo
Copy link
Contributor

☔ The latest upstream changes (presumably #22086) made this pull request unmergeable. Please resolve the merge conflicts.

@highfive highfive added the S-needs-rebase There are merge conflict errors. label Nov 6, 2018
@nox
Copy link
Contributor

nox commented Nov 22, 2018

I vaguely remember a discussion where we realised done_editing wasn't needed, did I dream that?

@nox nox added S-needs-code-changes Changes have not yet been made that were requested by a reviewer. and removed S-awaiting-review There is new code that needs to be reviewed. labels Nov 22, 2018
@Eijebong
Copy link
Contributor Author

Probably, I have nothing related to done_editing in my logs

@jdm
Copy link
Member

jdm commented Nov 25, 2019

Closing due to lack of activity.

@jdm jdm closed this Nov 25, 2019
bors-servo pushed a commit that referenced this pull request Jan 1, 2020
make stepUp, stepDown, valueAsNumber, valueAsDate, and list work in HTMLInputElement

<!-- Please describe your changes on the following line: -->
Steppy operation of input elements now functions. A few related tests still fail because of incorrect test expectations. A couple range reftests fail on what might be correct expectations; solving that involves layout, not DOM.
Main changes here:
- str.rs now has its datetime format parsers public, with some changes to align their output with chrono::NaiveDateTime and fix a bug in milliseconds validation
- HTMLInputElement has new attributes, and code behind them for relevant concepts
- servoparser/mod.rs now has some extra code to ensure that input sanitization happens at the right moment during input element creation; the spec is non-specific about when this happens, but it has to happen somewhere and in #21952 @Eijebong had independently come to the same conclusion as me about the timing.
- Some tests are added where WPT wasn't already testing functionality I was adding; Firefox and Chrome pass them, Safari fails some in a reasonably expected way
- Lots of test metadata changed to passing

One test continues to fail because 0.1 * 6 != 0.6 and the spec is written in abstractions instead of actual floating-point numbers; other test failures are WPT bugs I've reported as such and will write fixes for soon if no one else does.

---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix #25390 and fix #25388 and fix #19773 (except validation doesn't exist) and fix #25386

<!-- Either: -->
- [X] There are tests for these changes OR

<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->

<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
bors-servo pushed a commit that referenced this pull request Jan 10, 2020
make stepUp, stepDown, valueAsNumber, valueAsDate, and list work in HTMLInputElement

<!-- Please describe your changes on the following line: -->
Steppy operation of input elements now functions. A few related tests still fail because of incorrect test expectations. A couple range reftests fail on what might be correct expectations; solving that involves layout, not DOM.
Main changes here:
- str.rs now has its datetime format parsers public, with some changes to align their output with chrono::NaiveDateTime and fix a bug in milliseconds validation
- HTMLInputElement has new attributes, and code behind them for relevant concepts
- servoparser/mod.rs now has some extra code to ensure that input sanitization happens at the right moment during input element creation; the spec is non-specific about when this happens, but it has to happen somewhere and in #21952 @Eijebong had independently come to the same conclusion as me about the timing.
- Some tests are added where WPT wasn't already testing functionality I was adding; Firefox and Chrome pass them, Safari fails some in a reasonably expected way
- Lots of test metadata changed to passing

One test continues to fail because 0.1 * 6 != 0.6 and the spec is written in abstractions instead of actual floating-point numbers; other test failures are WPT bugs I've reported as such and will write fixes for soon if no one else does.

---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix #25390 and fix #25388 and fix #19773 (except validation doesn't exist) and fix #25386

<!-- Either: -->
- [X] There are tests for these changes OR

<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->

<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
bors-servo pushed a commit that referenced this pull request Jan 11, 2020
make stepUp, stepDown, valueAsNumber, valueAsDate, and list work in HTMLInputElement

<!-- Please describe your changes on the following line: -->
Steppy operation of input elements now functions. A few related tests still fail because of incorrect test expectations. A couple range reftests fail on what might be correct expectations; solving that involves layout, not DOM.
Main changes here:
- str.rs now has its datetime format parsers public, with some changes to align their output with chrono::NaiveDateTime and fix a bug in milliseconds validation
- HTMLInputElement has new attributes, and code behind them for relevant concepts
- servoparser/mod.rs now has some extra code to ensure that input sanitization happens at the right moment during input element creation; the spec is non-specific about when this happens, but it has to happen somewhere and in #21952 @Eijebong had independently come to the same conclusion as me about the timing.
- Some tests are added where WPT wasn't already testing functionality I was adding; Firefox and Chrome pass them, Safari fails some in a reasonably expected way
- Lots of test metadata changed to passing

One test continues to fail because 0.1 * 6 != 0.6 and the spec is written in abstractions instead of actual floating-point numbers; other test failures are WPT bugs I've reported as such and will write fixes for soon if no one else does.

---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix #25390 and fix #25388 and fix #19773 (except validation doesn't exist) and fix #25386

<!-- Either: -->
- [X] There are tests for these changes OR

<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->

<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
bors-servo pushed a commit that referenced this pull request Jan 11, 2020
make stepUp, stepDown, valueAsNumber, valueAsDate, and list work in HTMLInputElement

<!-- Please describe your changes on the following line: -->
Steppy operation of input elements now functions. A few related tests still fail because of incorrect test expectations. A couple range reftests fail on what might be correct expectations; solving that involves layout, not DOM.
Main changes here:
- str.rs now has its datetime format parsers public, with some changes to align their output with chrono::NaiveDateTime and fix a bug in milliseconds validation
- HTMLInputElement has new attributes, and code behind them for relevant concepts
- servoparser/mod.rs now has some extra code to ensure that input sanitization happens at the right moment during input element creation; the spec is non-specific about when this happens, but it has to happen somewhere and in #21952 @Eijebong had independently come to the same conclusion as me about the timing.
- Some tests are added where WPT wasn't already testing functionality I was adding; Firefox and Chrome pass them, Safari fails some in a reasonably expected way
- Lots of test metadata changed to passing

One test continues to fail because 0.1 * 6 != 0.6 and the spec is written in abstractions instead of actual floating-point numbers; other test failures are WPT bugs I've reported as such and will write fixes for soon if no one else does.

---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix #25390 and fix #25388 and fix #19773 (except validation doesn't exist) and fix #25386

<!-- Either: -->
- [X] There are tests for these changes OR

<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->

<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
bors-servo pushed a commit that referenced this pull request Jan 11, 2020
make stepUp, stepDown, valueAsNumber, valueAsDate, and list work in HTMLInputElement

<!-- Please describe your changes on the following line: -->
Steppy operation of input elements now functions. A few related tests still fail because of incorrect test expectations. A couple range reftests fail on what might be correct expectations; solving that involves layout, not DOM.
Main changes here:
- str.rs now has its datetime format parsers public, with some changes to align their output with chrono::NaiveDateTime and fix a bug in milliseconds validation
- HTMLInputElement has new attributes, and code behind them for relevant concepts
- servoparser/mod.rs now has some extra code to ensure that input sanitization happens at the right moment during input element creation; the spec is non-specific about when this happens, but it has to happen somewhere and in #21952 @Eijebong had independently come to the same conclusion as me about the timing.
- Some tests are added where WPT wasn't already testing functionality I was adding; Firefox and Chrome pass them, Safari fails some in a reasonably expected way
- Lots of test metadata changed to passing

One test continues to fail because 0.1 * 6 != 0.6 and the spec is written in abstractions instead of actual floating-point numbers; other test failures are WPT bugs I've reported as such and will write fixes for soon if no one else does.

---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix #25390 and fix #25388 and fix #19773 (except validation doesn't exist) and fix #25386

<!-- Either: -->
- [X] There are tests for these changes OR

<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->

<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
bors-servo pushed a commit that referenced this pull request Jan 11, 2020
make stepUp, stepDown, valueAsNumber, valueAsDate, and list work in HTMLInputElement

<!-- Please describe your changes on the following line: -->
Steppy operation of input elements now functions. A few related tests still fail because of incorrect test expectations. A couple range reftests fail on what might be correct expectations; solving that involves layout, not DOM.
Main changes here:
- str.rs now has its datetime format parsers public, with some changes to align their output with chrono::NaiveDateTime and fix a bug in milliseconds validation
- HTMLInputElement has new attributes, and code behind them for relevant concepts
- servoparser/mod.rs now has some extra code to ensure that input sanitization happens at the right moment during input element creation; the spec is non-specific about when this happens, but it has to happen somewhere and in #21952 @Eijebong had independently come to the same conclusion as me about the timing.
- Some tests are added where WPT wasn't already testing functionality I was adding; Firefox and Chrome pass them, Safari fails some in a reasonably expected way
- Lots of test metadata changed to passing

One test continues to fail because 0.1 * 6 != 0.6 and the spec is written in abstractions instead of actual floating-point numbers; other test failures are WPT bugs I've reported as such and will write fixes for soon if no one else does.

---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix #25390 and fix #25388 and fix #19773 (except validation doesn't exist) and fix #25386

<!-- Either: -->
- [X] There are tests for these changes OR

<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->

<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-needs-code-changes Changes have not yet been made that were requested by a reviewer. S-needs-rebase There are merge conflict errors.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants