1830466 - [CTW] When there are two consecutive line breaks, VoiceOver reads the line below the blank line when moving up and down.

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect, P2)

Description

[Marco Zehe (:MarcoZ)]

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:

1. With VoiceOver on, open data:text/html,<textarea cols="80"></textarea>
2. Focus the text field and type in some text.
3. Insert two NewLines by pressing Enter twice, and then enter some more text.
4. Press CMD+UpArrow to go to the start of the text field. Press CTRL+Option+L to read the current line.
5. 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.
6. 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.
7. 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.
8. 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.

Comment 1

[James Teh [:Jamie]]

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?

Comment 2

[Marco Zehe (:MarcoZ)]

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.

Comment 3

[James Teh [:Jamie]]

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

[Rares Doghi, Desktop QA]

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

[Eitan Isaacson [:eeejay]]

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.

Comment 6

[James Teh [:Jamie]]

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.

Comment 7

[James Teh [:Jamie]]

Attachment: Bug 1830466: Mac a11y: Don't try to search forward for a line end boundary on a blank line.

1. 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.
2. 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 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fba12a7c9b46
Mac a11y: Don't try to search forward for a line end boundary on a blank line. r=eeejay

Comment 9

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/fba12a7c9b46

Comment 10

[Marco Zehe (:MarcoZ)]

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?

Comment 11

[James Teh [:Jamie]]

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

[Rares Doghi, Desktop QA]

Verified as fixed in our latest Nightly build 115.0a1 (2023-05-10).

Comment 13

[Pascal Chevrel:pascalc]

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

Comment 14

[James Teh [:Jamie]]

Sorry about that. I've now requested uplift on bug 1826853.

Comment 15

[Pascal Chevrel:pascalc]

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

[Pascal Chevrel:pascalc]

https://hg.mozilla.org/releases/mozilla-beta/rev/429d2a4fd973

Comment 17

[Rares Doghi, Desktop QA]

Verified as fixed in our latest Beta 114.0b5.