-
Notifications
You must be signed in to change notification settings - Fork 27
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
Remove /html/semantics/forms/the-input-element/selection-pointer.html from Interop 2023 #313
Comments
That said the spec issue has not been discussed for 5 years. Last meaningful updates
Should the discussion restart on the WG to test if there is new will on moving forward? cc @rniwa too |
AFAIK, there is still recent discussion about multiple ranges in w3c/selection-api#161. |
@mfreed7 can you review this proposed change? |
This seems reasonable. |
Hmm, I'm still not convinced about the multi-range thing being discussed on w3c/selection-api#161. But aside from that - rather than just remove the test entirely, perhaps it's possible to instead modify the test so that it's compatible with multiple ranges? E.g. for the cases where the selection includes an unselectable item, make the test pass in either the single-range or multi-range support case? |
We discussed this in #323 and the conclusion is if that if the test can be updated to tolerate either behavior for selections and ranges, everyone will be happy. |
See [1] for context. This CL makes this test pass in the case that multiple range support is present *and* selecting across an `<input>` creates multiple ranges. Note that in my local testing, only a single range is created on all rendering engines (Blink, WebKit, and Gecko) when the user selects across an `<input>`. Thus, I was not able to test the newly added code here. I did attempt to verify that it would work correctly, however, and I believe it will. [1] web-platform-tests/interop#313 Change-Id: I88c88fcca47da627a0be9de518b76bbbcc07964b
See [1] for context. This CL makes this test pass in the case that multiple range support is present *and* selecting across an `<input>` creates multiple ranges. Note that in my local testing, only a single range is created on all rendering engines (Blink, WebKit, and Gecko) when the user selects across an `<input>`. Thus, I was not able to test the newly added code here. I did attempt to verify that it would work correctly, however, and I believe it will. [1] web-platform-tests/interop#313 Change-Id: I88c88fcca47da627a0be9de518b76bbbcc07964b
So I've updated the test here: web-platform-tests/wpt#39753 I wasn't able to run the actual test locally on Gecko or WebKit, but my local testing looks like it should have worked. I can tweak as needed, if someone points out an issue. |
See [1] for context. This CL makes this test pass in the case that multiple range support is present *and* selecting across an `<input>` creates multiple ranges. Note that in my local testing, only a single range is created on all rendering engines (Blink, WebKit, and Gecko) when the user selects across an `<input>`. Thus, I was not able to test the newly added code here. I did attempt to verify that it would work correctly, however, and I believe it will. [1] web-platform-tests/interop#313 Change-Id: I88c88fcca47da627a0be9de518b76bbbcc07964b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4492089 Reviewed-by: Di Zhang <[email protected]> Auto-Submit: Mason Freed <[email protected]> Commit-Queue: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/main@{#1137412}
See [1] for context. This CL makes this test pass in the case that multiple range support is present *and* selecting across an `<input>` creates multiple ranges. Note that in my local testing, only a single range is created on all rendering engines (Blink, WebKit, and Gecko) when the user selects across an `<input>`. Thus, I was not able to test the newly added code here. I did attempt to verify that it would work correctly, however, and I believe it will. [1] web-platform-tests/interop#313 Change-Id: I88c88fcca47da627a0be9de518b76bbbcc07964b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4492089 Reviewed-by: Di Zhang <[email protected]> Auto-Submit: Mason Freed <[email protected]> Commit-Queue: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/main@{#1137412}
Results for Chrome, Firefox and Safari can now be seen at https://wpt.fyi/results/html/semantics/forms/the-input-element/selection-pointer.html?label=master&label=experimental&product=chrome&product=firefox&product=safari&aligned and all tests are passing. Closing this issue. |
…er.html to support multi-range, a=testonly Automatic update from web-platform-tests Update the-input-element/selection-pointer.html to support multi-range See [1] for context. This CL makes this test pass in the case that multiple range support is present *and* selecting across an `<input>` creates multiple ranges. Note that in my local testing, only a single range is created on all rendering engines (Blink, WebKit, and Gecko) when the user selects across an `<input>`. Thus, I was not able to test the newly added code here. I did attempt to verify that it would work correctly, however, and I believe it will. [1] web-platform-tests/interop#313 Change-Id: I88c88fcca47da627a0be9de518b76bbbcc07964b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4492089 Reviewed-by: Di Zhang <[email protected]> Auto-Submit: Mason Freed <[email protected]> Commit-Queue: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/main@{#1137412} -- wpt-commits: 655997d590b0d2c50a08e565e0cbab272b4b00e4 wpt-pr: 39753
…er.html to support multi-range, a=testonly Automatic update from web-platform-tests Update the-input-element/selection-pointer.html to support multi-range See [1] for context. This CL makes this test pass in the case that multiple range support is present *and* selecting across an `<input>` creates multiple ranges. Note that in my local testing, only a single range is created on all rendering engines (Blink, WebKit, and Gecko) when the user selects across an `<input>`. Thus, I was not able to test the newly added code here. I did attempt to verify that it would work correctly, however, and I believe it will. [1] web-platform-tests/interop#313 Change-Id: I88c88fcca47da627a0be9de518b76bbbcc07964b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4492089 Reviewed-by: Di Zhang <[email protected]> Auto-Submit: Mason Freed <[email protected]> Commit-Queue: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/main@{#1137412} -- wpt-commits: 655997d590b0d2c50a08e565e0cbab272b4b00e4 wpt-pr: 39753
Test List
https://wpt.fyi/results/html/semantics/forms/the-input-element/selection-pointer.html?label=experimental&label=master&aligned
Rationale
Per discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=1738866 this test fails in Firefox because we support multiple selections. There's a spec issue about this at w3c/selection-api#41 and it looks like there's some interest to support multiple selections also in Chromium.
cc @masayuki-nakano
The text was updated successfully, but these errors were encountered: