[CTW] When there are two consecutive line breaks, VoiceOver reads the line below the blank line when moving up and down.
Categories
(Core :: Disability Access APIs, defect, P2)
Tracking
()
People
(Reporter: MarcoZ, Assigned: Jamie)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta+
|
Details |
After the fix for bug 1827557, there is still one edge case where VoiceOver does not read the correct line when navigating with up and down arrows. To reproduce:
- With VoiceOver on, open data:text/html,<textarea cols="80"></textarea>
- Focus the text field and type in some text.
- Insert two NewLines by pressing Enter twice, and then enter some more text.
- Press CMD+UpArrow to go to the start of the text field. Press CTRL+Option+L to read the current line.
- Now press DownArrow and listen to what VoiceOver says when you reach the blank line you inserted earlier.
- Expected: VoiceOver would simply say "New line", as it does when it encounters an empty line with only a new line character.
- Actual: VoiceOver reads the line below the blank line. If you press down arrow once more, and the caret moves before the first character of that line, the line is read again. this time, the reading is correct.
- Press UpArrow again to return to the blank line.
- Expected: VoiceOver should say "New line" or similar again.
- Actual: VoiceOver again reads the line below the current blank line. So the direction doesn't matter, it is always the next line that is fetched when VoiceOver gets the information to read the current line.
- Press CMD+DownArrow to jump to the very end of the text area. Press Return to enter a blank line at the end of the text area.
- Press UpArrow. VoiceOver will read the previous line, which is the last line of text, properly. Press DownArrow again.
- Result: This time, VoiceOver says "new line", indicating that this line is blank. This indicates that the wrong behavior only happens if there is actually more text to follow after two consecutive line ending characters. If it is the last line, the behavior is correct.
I suspect this is something in the new text implementation jumping too far ahead to the end of the next line when it should actually stop at the line ending character immediately following the caret.
Note that I only see this behavior in MacOS, not in Windows, so it is something specific to the Mac code that is triggering this wrong'ish behavior.
Assignee | ||
Comment 1•1 year ago
|
||
I think this is probably happening because on Mac, we use the line start boundary to find the start of the line and the line end boundary to find the end of the line. I believe that's consistent with what other browsers do. On Windows, we use the line start boundary in both directions for symmetry. The practical difference is that on Mac, we exclude the \n from the end of the line, whereas on Windows, we don't.
In the case of a blank line, the fact that we use the line end boundary means we'll keep searching for the next \n, which of course is at the end of the next line, not the current one.
This should be pretty easy to fix. What's unclear to me is whether we should return \n for a blank line or not. Normally, Mac doesn't want us to include the \n, but maybe a blank line is different.
Eitan, are you able to find out what Safari does for a blank line? For example:
data:text/html,<textarea>a%0a%0ab
If you iterate by LineRange, what do you get?
Assignee | ||
Updated•1 year ago
|
Reporter | ||
Comment 2•1 year ago
|
||
I just checked your example, and on the blank line, VoiceOver definitely says "new line" on that blank line. That leads me to believe that Safari does return the line end character in this case.
Assignee | ||
Comment 3•1 year ago
|
||
I thought so too and I'd guess that's probably true. However, it's slightly possible that it gets an empty string, but infers the fact that it's a new line based on the granularity in the caret event. (Mac caret events specify the movement granularity as part of the event info.) I'd prefer to be sure of the raw string Safari returns.
Comment 4•1 year ago
|
||
I was also able to reproduce this issue, in previous builds Voice over would read the Previous line when we moved to an empty line but now it reads the next one, In Safari even if we have 2 empty lines its always beeing read as "New Line" each time we reach one of those lines.
Comment 5•1 year ago
|
||
In Firefox Nightly I get:
0 {'lineRight': 'a', 'line': 'a', 'lineLeft': 'a'}
1 {'lineRight': 'a\n', 'line': 'a', 'lineLeft': 'a'}
2 {'lineRight': 'b', 'line': '\nb', 'lineLeft': 'a'}
3 {'lineRight': 'b', 'line': 'b', 'lineLeft': '\nb'}
4 {'lineRight': 'b', 'line': 'b', 'lineLeft': 'b'}
In Safari I get:
0 {'lineRight': '\xef\xbf\xbc', 'line': '\xef\xbf\xbc', 'lineLeft': ''}
1 {'lineRight': '', 'line': 'a', 'lineLeft': 'a'}
2 {'lineRight': 'b', 'line': '', 'lineLeft': 'a'}
3 {'lineRight': 'b', 'line': 'b', 'lineLeft': ''}
4 {'lineRight': '', 'line': 'b', 'lineLeft': 'b'}
Note the embedded char Safari returns at index 0.
Assignee | ||
Comment 6•1 year ago
|
||
Interesting. So WebKit returns AN empty string for a blank line, not "\n". In fact, WebKit never includes the line feed in returned lines, but Gecko currently sometimes includes a line feed at the start of a line.
For this bug, let's just deal with the blank line case.
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Comment 7•1 year ago
|
||
- CachedTextMarker::LineRange: If the line starts with a line feed, it's a blank line and the end boundary is the same as the start boundary, so just return the start for both.
- TextLeafRange::FindLineEnd: If the origin is the empty last line of a textarea, we actually do want the line starting at the next character, so don't skip forward a character. Also don't skip back to the line feed after the search, since that would be the end of the previous line.
Comment 9•1 year ago
|
||
bugherder |
Reporter | ||
Comment 10•1 year ago
|
||
I am happy to report that this is fixed in the latest Nightly build 115.0.a1 (20230510213701). Text fields with blank lines now read very nicely with VoiceOver.
Would this be a good candidate for a 114 beta uplift so more users can benefit from it more quickly?
Assignee | ||
Comment 11•1 year ago
|
||
Comment on attachment 9332160 [details]
Bug 1830466: Mac a11y: Don't try to search forward for a line end boundary on a blank line.
Beta/Release Uplift Approval Request
- User impact if declined: Blank lines not reported correctly for VoiceOver screen reader users.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Small change specific to blank lines in Mac text a11y. Covered by automated tests.
- String changes made/needed:
- Is Android affected?: No
Comment 12•1 year ago
|
||
Verified as fixed in our latest Nightly build 115.0a1 (2023-05-10).
Comment 13•1 year ago
|
||
Jamie, the patch does not graft cleanly to the beta branch as bug 1826853 touched these files as well. Do you want to update the patch for beta or do you want to also uplift bug 1826853 ? Thanks
Assignee | ||
Comment 14•1 year ago
|
||
Sorry about that. I've now requested uplift on bug 1826853.
Comment 15•1 year ago
|
||
Comment on attachment 9332160 [details]
Bug 1830466: Mac a11y: Don't try to search forward for a line end boundary on a blank line.
Approved for 114 beta 5, thanks.
Comment 16•1 year ago
|
||
bugherder uplift |
Comment 17•1 year ago
|
||
Verified as fixed in our latest Beta 114.0b5.
Updated•1 year ago
|
Updated•1 year ago
|
Description
•