| Summary: | Braille display is blank in contenteditable elements when the field is followed by another element. | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Andres Gonzalez <andresg_22> | ||||||||
| Component: | New Bugs | Assignee: | Andres Gonzalez <andresg_22> | ||||||||
| Status: | RESOLVED FIXED | ||||||||||
| Severity: | Normal | CC: | aboxhall, apinheiro, cfleizach, darin, dmazzoni, ews-watchlist, jcraig, jdiggs, samuel_white | ||||||||
| Priority: | P2 | Keywords: | InRadar | ||||||||
| Version: | WebKit Nightly Build | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Andres Gonzalez
2021-08-31 08:12:29 PDT
To reproduce: 1. Safari with VoiceOver and Braille output. 2. open a page containing the following HTML snippet: <div id="textfield" contenteditable="true">this is a test.</div> <button>Submit</button> Focus the text field and observe Braille output. Created attachment 436887 [details]
Patch
Created attachment 436944 [details]
Patch
Comment on attachment 436944 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=436944&action=review > Source/WebCore/ChangeLog:15 > + ranges in text fields to match the number of charaters in the line. if we're changing behavior, then I think we need a new test that will capture that Created attachment 437105 [details]
Patch
(In reply to chris fleizach from comment #5) > Comment on attachment 436944 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=436944&action=review > > > Source/WebCore/ChangeLog:15 > > + ranges in text fields to match the number of charaters in the line. > > if we're changing behavior, then I think we need a new test that will > capture that Added test cases for single and multiline TextArea and content editable, and single line input text field. Comment on attachment 437105 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=437105&action=review > Source/WebCore/accessibility/AccessibilityRenderObject.cpp:2468 > + return it.text().length() == 1 && it.text()[0] == '\n'; is it worth caching it.text(). it must cost something to gather the text for a range (In reply to chris fleizach from comment #8) > Comment on attachment 437105 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=437105&action=review > > > Source/WebCore/accessibility/AccessibilityRenderObject.cpp:2468 > > + return it.text().length() == 1 && it.text()[0] == '\n'; > > is it worth caching it.text(). it must cost something to gather the text for > a range It is an inline accessor to m_text: StringView text() const { ASSERT(!atEnd()); return m_text; } Committed r281920 (241229@main): <https://commits.webkit.org/241229@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 437105 [details]. Comment on attachment 437105 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=437105&action=review >>> Source/WebCore/accessibility/AccessibilityRenderObject.cpp:2468 >>> + return it.text().length() == 1 && it.text()[0] == '\n'; >> >> is it worth caching it.text(). it must cost something to gather the text for a range > > It is an inline accessor to m_text: > > StringView text() const { ASSERT(!atEnd()); return m_text; } Pushing in the opposite direction: I’m pretty sure you can just write: return it.text() == "\n"; And the code will be nearly as efficient; don’t have to write out the length/character check. |