-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
[meta] Implement value sanitizations for different input modes #19172
Comments
Hi! If you have any questions regarding this issue, feel free to make a comment here, or ask it in the If you intend to work on this issue, then add |
@highfive: assign me |
Hey @tigercosmos! Thanks for your interest in working on this issue. It's now assigned to you! |
@KiChjang Can I divide it to several parts and solve them one by one? Maybe two or three? |
@tigercosmos Sure! Just comment and make a list of the ones that you'd like to solve. |
Keeping this open for other potential contributors. |
Seems servo/components/script/dom/htmlinputelement.rs Lines 896 to 899 in a3f2fae
|
That is incorrect. I can find them under the servo/components/script/dom/htmlinputelement.rs Lines 496 to 500 in 33fa728
|
That just get the value. But we need to do something? e.g. min should be number. |
I assume the reason why you're asking is because the spec mentions In addition, the spec defines the value sanitization algorithm as "if the value of the element is not a valid date string, then set it to the empty string instead". The The valid date strings algorithm is what you will need to implement, and I think the appropriate place to put that algorithm would be in |
Going to do the color one |
I believe @Eijebong is also working on the number and range type inputs. |
Right, sorry I forgot to put it there. |
@tigercosmos I haven't heard back from you for a while, do you need any help? Any questions? |
@KiChjang I am stuck in other issues (19280) ... and preparing for midterm exams recently. |
I am back, and working on |
I'm going to work on the |
Oh, missed that. @KiChjang Could you update the initial issue and name the selected parts? |
I believe these are unassigned:
But some would be related to |
Then I'll work on the |
That would be great! |
Implemented sanitize_value for time input Implemented value sanitization for `<input type=time/>`. The value has the be valid time string (https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#valid-time-string) or set to empty string. --- The following test results look expected to me, but I'm not sure: ``` ▶ Unexpected subtest result in /html/semantics/forms/the-input-element/type-change-state.html: │ FAIL [expected PASS] change state from time to text │ → assert_equals: input.value should be foobar after change of state expected " foobar " but got "" │ FAIL [expected PASS] change state from time to search │ → assert_equals: input.value should be foobar after change of state expected " foobar " but got "" │ FAIL [expected PASS] change state from time to tel │ → assert_equals: input.value should be foobar after change of state expected " foobar " but got "" │ FAIL [expected PASS] change state from time to url │ → assert_equals: input.value should be foobar after change of state expected "foobar" but got "" │ FAIL [expected PASS] change state from time to password │ → assert_equals: input.value should be foobar after change of state expected " foobar " but got "" │ │ @http://web-platform.test:8000/html/semantics/forms/the-input-element/type-change-state.html:53:15 │ Test.prototype.step@http://web-platform.test:8000/resources/testharness.js:1489:20 │ test@http://web-platform.test:8000/resources/testharness.js:511:9 └ @http://web-platform.test:8000/html/semantics/forms/the-input-element/type-change-state.html:37:9 ▶ Unexpected subtest result in /html/semantics/forms/the-input-element/type-change-state.html: │ FAIL [expected PASS] change state from color to time │ → assert_equals: input.value should be #000000 after change of state expected "#000000" but got "" │ │ @http://web-platform.test:8000/html/semantics/forms/the-input-element/type-change-state.html:55:15 │ Test.prototype.step@http://web-platform.test:8000/resources/testharness.js:1489:20 │ test@http://web-platform.test:8000/resources/testharness.js:511:9 └ @http://web-platform.test:8000/html/semantics/forms/the-input-element/type-change-state.html:37:9 ``` All other tests do now `PASS` instead of `FAIL`. --- - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes fix *part of* #19172 - [x] There are tests for these changes - [ ] All tests `PASS` <!-- 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/19379) <!-- Reviewable:end -->
I'd rather not, most of the string parsing/validation logic is located in |
@Eijebong Are you still working on |
implement valid week string <!-- Please describe your changes on the following line: --> implement valid week string part of #19172 r? @KiChjang --- <!-- 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] There are tests for these changes <!-- 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. --> <!-- 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/19559) <!-- Reviewable:end -->
I just found that @SWW13' s |
|
implement valid DatetimeLocal input <!-- Please describe your changes on the following line: --> implement valid Date time Local input part of #19172 --- <!-- 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 #19587 fix #19603(github issue number if applicable). <!-- Either: --> - [ ] There are tests for these changes OR - [ ] These changes do not require tests because _____ <!-- 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. --> <!-- 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/19602) <!-- Reviewable:end -->
implement valid DatetimeLocal input <!-- Please describe your changes on the following line: --> implement valid Date time Local input part of #19172 --- <!-- 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 #19587 fix #19603(github issue number if applicable). <!-- Either: --> - [ ] There are tests for these changes OR - [ ] These changes do not require tests because _____ <!-- 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. --> <!-- 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/19602) <!-- Reviewable:end -->
I've started working on basic support for My code is here. I used the standard f64 parser, just with a few changes where the browser spec is stricter than what rust allows. Is this approach Ok? Currently I don't handle the |
@NLincoln this issue doesn't need to handle min, max, or step. I think you can open PR and that would be easier to discuss about the code. |
👍 I just opened one. |
…r=KiChjang number input type validations I used rust's builtin float parser to implement this. Rust's parser is more permissive than what browsers support (in this case), so I added some code to handle those edge cases. This passes all the prewritten test cases locally, but I fell asleep last night before updating the manifests 😅 --- - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes are part of #19172 <!-- Either: --> - [X] There are tests for these changes <!-- 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/19730) <!-- Reviewable:end -->
…r=KiChjang number input type validations I used rust's builtin float parser to implement this. Rust's parser is more permissive than what browsers support (in this case), so I added some code to handle those edge cases. This passes all the prewritten test cases locally, but I fell asleep last night before updating the manifests 😅 --- - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes are part of #19172 <!-- Either: --> - [X] There are tests for these changes <!-- 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/19730) <!-- Reviewable:end -->
let me finish the last one |
Hey @tigercosmos! Thanks for your interest in working on this issue. It's now assigned to you! |
I have opened the last one PR in this issue. |
implement range input sanitization <!-- Please describe your changes on the following line: --> implement range input sanitation. Since there is no `min`, `max`, `step` implementation currently, this should be continued in the future. r? KiChjang --- <!-- 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 #19172 (github issue number if applicable). <!-- Either: --> - [ ] There are tests for these changes OR - [ ] These changes do not require tests because _____ <!-- 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. --> <!-- 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/19761) <!-- Reviewable:end -->
Is Ref: https://html.spec.whatwg.org/multipage/input.html#e-mail-state-(type=email) |
Yes, let's reopen the issue. |
I've instead filed #21810, which contains other things that also needs attention for value sanitization. |
#18262 laid the groundwork for this, but we're still missing value sanitizations for:
All of the missing algorithms above are expected to be implemented in this function:
servo/components/script/dom/htmlinputelement.rs
Lines 1125 to 1190 in 6e844f2
The implementation for these value sanitizations are given by the spec, which I have linked accordingly. When each of these are implemented, some subtests under
tests/wpt/web-platform-tests/html/semantics/forms/the-input-element/type-change-state.html
should be expected to PASS instead. Some other tests under the same directory may also pass as a result of a correct implementation.If you want to help out with this, please comment on this issue or reach out on IRC (
#servo
inirc.mozilla.org
), and we'll find one which is interesting to you; or, you can also file an issue and mention this one, and I'll get it assigned to you.The text was updated successfully, but these errors were encountered: