-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Fix duplicate carets in <textarea> #40837
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
Conversation
Signed-off-by: Freya Arbjerg <git@arbjerg.dev>
7531628 to
8dd831b
Compare
|
🔨 Triggering try run (#19613347355) for Linux (WPT) |
|
Test results for linux-wpt from try job (#19613347355): Flaky unexpected result (30)
Stable unexpected results that are known to be intermittent (25)
|
|
✨ Try run (#19613347355) succeeded. |
|
CC @jdm |
|
This will make it possible to edit Github PR easily @mrego 🎉 |
|
Note that this line of code used to be exactly the same but was changed in #36461. I'm quite suspicious of all of the caret code. |
I'm not a big fan of it either. Yesterday I was trying to shoehorn carets into empty ( My testing has obviously been biased because I only write in Latin script languages. I think I will play around with other scripts and ZWS and see if I encounter any issues with this PR. |
|
🔨 Triggering try run (#19631988998) for Linux (WPT) |
|
Test results for linux-wpt from try job (#19631988998): Flaky unexpected result (41)
Stable unexpected results that are known to be intermittent (35)
|
|
✨ Try run (#19631988998) succeeded. |
|
After debugging the layout crate further (#40839 is very complicated) i've grown more confident in the change in this PR. I think I would like to add a few reftests for the caret placement, either as part of this PR or my next. |
|
I tested the crashing testcases from #36449 with this change and could not reproduce any crashes, or any other input weirdness. |
|
This change makes sense to me:
With the change in this PR, we pass a range that represents only the current glyph run, so the intersection with the text run's selection range is actually meaningful and we only get one TextRunLineItem that has a caret position included. |
|
I can't think of how to write reftests for this without exposing additional APIs for manipulating the cursor position in text inputs. A testdriver.js test would be able to do it by sending keyboard inputs to the focused text input, but those tests can't be used as reference tests with screenshots. I would:
That being said, I'm having trouble figuring out how to write the actual reference part of the test right now so that it's different from the actual content being tested. |
I was talking with a friend about WPT testing and she brought up reftests. It seems that she meant to talk about visual tests. I've read that visual tests are generally discouraged as they are rarely run. Would a visual test be relevant?
Why not use these two functions? https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/focus Both functions seem to work on |
|
Aha, yeah, I haven't come across https://web-platform-tests.org/writing-tests/visual.html before. I don't think we'll get any use out of that, unfortunately; anything that isn't run as part of our automated CI runs is doomed to be ignored. |
jdm
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no good story for how to create an automated test for this change, so let's get it into the hands of manual testing instead!
|
One way to test carets on WPT is to use the Only Chromium supports it so far, and I have no clue how easy/complex would be to support it in Servo, maybe initially adding some basic support so the caret doesn't blink would be good enough for these testing purposes. |
Well this one is easy, the caret doesn't actually blink in Servo. It would be good to add if we do ever create a reftest/visual test. Though it still doesn't answer how to actually create a reference for the reftest. |
Both the reference and the test would have to use |
|
Both the test and the reference would render the same with or without this bug. This bug was independent of how the cursor was moved |
|
True, I haven't tested it extensively, it might be the case that for this bug in particular both would have the same output. I was thinking more on how to test the caret position in general and suggesting some idea, that was all. I guess for this bug in particular implementing some more new things like |
This fixes a bug where <textarea> would render with many carets. Reports vary, but in my case it would would be at the start and end of every "word", as long as those cursors came before the actual cursor.
The actual cursor would render normally, except that it does not render immediately after a line break. This appears to be a separate issue.
The issue occurs because
push_glyph_store_to_unbreakable_segmentgets passed too long of a range. This bypasses the check here:servo/components/layout/flow/inline/mod.rs
Lines 1438 to 1440 in bbbfe6d
Testing: Tested with
./mach test-unit. No new tests were added. Perhaps someone has an idea of how one could test this. Also tested manually in multiple scenarios, including with a text input. I was not able to get Servo to soft wrap in a textbox, maybe Servo does not support that currently. Ultimately I am not super confident about this solution as it interacts with line wrapping, and I would like to hear some feedbackFixes: #40075