1672700 - Rich text editing: Braille is not tracking text and the cursor when composing documents in contentEditables, with and without ARIA roles.

Status: RESOLVED FIXED

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

Description

[Marco Zehe (:MarcoZ)]

This was an issue before, and after it had been working at some point, or I think it had, has been broken again. Speech is fine, Braille is not.

Steps:

1. Load Twitter and log in.
2. Press n to compose a new tweet.
   • VoiceOver will say "Compose tweet dialog", "What's happening text field", "object replacement character".
3. That object replacement character is all that's shown on the braille display. Start typing.
   • Expected: Braille should show what you type.
   • Actual: It remains mostly blank, only shows that object replacement character.
4. Arrow left and right.
   • Expected: Speech should speak the characters, and Braille should follow with the cursor over the text.
   • Actual: Speech works correctly, Braille still remains empty.
5. Delete some text.
   • Expected: VoiceOver should speak deleted characters. Braille should show text getting shorter.
   • Actual: Neither works.

Comment 1

[Marco Zehe (:MarcoZ)]

MozRegression didn't prove to be useful. It does work until a certain point, then stops working altogether. Starting out with:

data:text/html,<div tabindex="0" role="textbox" aria-multiline="true" contentEditable><p></p></div>

And focusing it, braille tracks as long as I type until I press Enter.

From that point on, braille stops working. Speech continues to track.

If I prepopulate the paragraph with text, or have two paragraphs to start with, Braille doesn't track at all.

Even a <br/> element is enough to make Braille not track.

I have also reproduced this in Slack, Gmail when composing a message, etc.
ContentEditables with rich content are still throwing off some text marker stuff. We basically shouldn't ever expose embedded characters, everything should be flattened I believe.

Comment 2

[Marco Zehe (:MarcoZ)]

Similar issues have been observed in Gmail, and even in simple data URLs with prepopulated contentEditables. Generalizing the bug summary.

Comment 3

[Marco Zehe (:MarcoZ)]

Closely related to bug 1674487 and bug 1676662, so nominating for including in 85 for now.

Comment 4

[Eitan Isaacson [:eeejay]]

Attachment: Bug 1672700 - Refactor mac input test. r?morgan!

This also irons out some event syncing issues. We need to wait for selection changes in the future patch in order to take advantage of selection caching.

Comment 5

[Eitan Isaacson [:eeejay]]

Attachment: Bug 1672700 - Make mozTextAccessible attribute getters use GeckoTextMarker. r?morgan!

This allows contenteditable textboxes to work correctly with flattened text values.

The attribute setters, aside from AXValue, don't work in Chrome or Safari with aria textboxes,
so those are not a high priority. These include:

• AXSelectedText
• AXSelectedTextRange
• AXVisibleCharacterRange

In addition, AXVisibleCharacterRange's getter doesn't function as expected in Chrome or Safari either, so I didn't touch it.

Depends on D97628

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1ad690f5f41a
Refactor mac input test. r=morgan
https://hg.mozilla.org/integration/autoland/rev/bb7606e92697
Make mozTextAccessible attribute getters use GeckoTextMarker. r=morgan

Comment 7

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/1ad690f5f41a
https://hg.mozilla.org/mozilla-central/rev/bb7606e92697