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

Disallow mutating the internals of TextInput #20051

Merged
merged 1 commit into from Feb 22, 2018

Conversation

jonleighton
Copy link
Contributor

@jonleighton jonleighton commented Feb 14, 2018

The TextInput::assert_ok_selection() method is meant to ensure that we
are not getting into a state where a selection refers to a location in
the control's contents which doesn't exist.

However, before this change we could have a situation where the
internals of the TextInput are changed by another part of the code,
without using its public API. This could lead to us having an invalid
selection.

I did manage to trigger such a situation (see the test added in this
commit) although it is quite contrived. There may be others that I
didn't think of, and it's also possible that future changes could
introduce new cases. (Including ones which trigger panics, if indexing
is used on the assumption that the selection indices are always valid.)

The current HTML specification doesn't explicitly say that
selectionStart/End must remain within the length of the content, but
that does seems to be the consensus reached in a discussion of this:

whatwg/html#2424

The test case I've added here is currently undefined in the spec which
is why I've added it in tests/wpt/mozilla.


This change is Reviewable

@highfive
Copy link

Heads up! This PR modifies the following files:

  • @asajeffrey: components/script/dom/htmltextareaelement.rs, components/script/dom/htmlinputelement.rs, components/script/dom/textcontrol.rs, components/script/textinput.rs
  • @fitzgen: components/script/dom/htmltextareaelement.rs, components/script/dom/htmlinputelement.rs, components/script/dom/textcontrol.rs, components/script/textinput.rs
  • @KiChjang: components/script/dom/htmltextareaelement.rs, components/script/dom/htmlinputelement.rs, components/script/dom/textcontrol.rs, components/script/textinput.rs

@highfive highfive added the S-awaiting-review There is new code that needs to be reviewed. label Feb 14, 2018
@highfive
Copy link

warning Warning warning

  • These commits include an empty title element (<title></title>). Consider adding appropriate metadata.


if *textinput.single_line_content() != value {
// Steps 1-2
textinput.set_content(value, update_text_cursor);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Bit of a shame to reorder this, but it does prevent us setting the value, then getting it for the sanitize step and then setting it again after sanitization... and the outcome is the same.

@jdm jdm assigned jdm and unassigned wafflespeanut Feb 14, 2018
// Step 4.
if update_text_cursor {
self.sanitize_value();
self.sanitize_value(&mut value);
Copy link
Member

Choose a reason for hiding this comment

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

No need to check update_text_cursor any more.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done (although that's not really specific to this change, since update_text_cursor is/was always true here)

@jdm jdm 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 Feb 15, 2018
@highfive highfive added S-awaiting-review There is new code that needs to be reviewed. and removed S-needs-code-changes Changes have not yet been made that were requested by a reviewer. labels Feb 15, 2018
The TextInput::assert_ok_selection() method is meant to ensure that we
are not getting into a state where a selection refers to a location in
the control's contents which doesn't exist.

However, before this change we could have a situation where the
internals of the TextInput are changed by another part of the code,
without using its public API. This could lead to us having an invalid
selection.

I did manage to trigger such a situation (see the test added in this
commit) although it is quite contrived. There may be others that I
didn't think of, and it's also possible that future changes could
introduce new cases. (Including ones which trigger panics, if indexing
is used on the assumption that the selection indices are always valid.)

The current HTML specification doesn't explicitly say that
selectionStart/End must remain within the length of the content, but
that does seems to be the consensus reached in a discussion of this:

whatwg/html#2424

The test case I've added here is currently undefined in the spec which
is why I've added it in tests/wpt/mozilla.
@jdm
Copy link
Member

jdm commented Feb 22, 2018

@bors-servo: r+

@bors-servo
Copy link
Contributor

📌 Commit 32f7812 has been approved by jdm

@highfive 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. labels Feb 22, 2018
@bors-servo
Copy link
Contributor

⌛ Testing commit 32f7812 with merge f6463c8...

bors-servo pushed a commit that referenced this pull request Feb 22, 2018
Disallow mutating the internals of TextInput

The TextInput::assert_ok_selection() method is meant to ensure that we
are not getting into a state where a selection refers to a location in
the control's contents which doesn't exist.

However, before this change we could have a situation where the
internals of the TextInput are changed by another part of the code,
without using its public API. This could lead to us having an invalid
selection.

I did manage to trigger such a situation (see the test added in this
commit) although it is quite contrived. There may be others that I
didn't think of, and it's also possible that future changes could
introduce new cases. (Including ones which trigger panics, if indexing
is used on the assumption that the selection indices are always valid.)

The current HTML specification doesn't explicitly say that
selectionStart/End must remain within the length of the content, but
that does seems to be the consensus reached in a discussion of this:

whatwg/html#2424

The test case I've added here is currently undefined in the spec which
is why I've added it in tests/wpt/mozilla.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/20051)
<!-- Reviewable:end -->
@bors-servo
Copy link
Contributor

☀️ 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: jdm
Pushing f6463c8 to master...

@bors-servo bors-servo merged commit 32f7812 into servo:master Feb 22, 2018
@highfive highfive removed the S-awaiting-merge The PR is in the process of compiling and running tests on the automated CI. label Feb 22, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants