1764500 - [CTW] JAWS treats a document as a read only edit if it contains a contentEditable

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[James Teh [:Jamie]]

If a document contains a contentEditable, JAWS seems to think the entire document is a read only edit. You can tab to the actual contentEditable, but something weird is going on with the virtual cursor/buffer there. Example:
data:text/html,before<div contenteditable role="textbox">editable</div>after
This doesn't seem to happen with an <input>.

I have no idea what's going on here. I've contacted Vispero for assistance and they're looking into it.

Comment 1

[James Teh [:Jamie]]

I think I've tracked this down. It seems the document gets the editable state when a contentEditable is present. What's strange is that this doesn't happen with the cache disabled. My guess is that the state is present when we push the cache but gets cleared later without a state change event, so we don't update the cache. The question is why it's present in the first place and/or why we don't fire an event.

This is probably also the cause behind bug 1681735, which impacts Orca regardless of CTW.

Comment 3

[James Teh [:Jamie]]

Attachment: Bug 1764500: Fire correct state change events when designMode is changed on a document.

Previously, we used the obs_documentCreated observer message fired by editor.
However, this is fired when an editor is created anywhere in the document, even if it's for a descendant.
This meant that we were firing an editable state change on the document when a descendant became contentEditable.
In turn, this resulted in the document always having the editable state in the cache if there was a contentEditable descendant.

This message also isn't fired if an editor already exists (e.g. for a contentEditable descendant) and designMode is turned on for the document.
This meant that we wouldn't fire an event in that case, resulting in an incorrect cache.

There is no usable equivalent to detect when designMode is turned off.
While there is obs_documentWillBeDestroyed, that doesn't ever seem to get fired.
This meant that we didn't fire a state change when designMode was turned off, also resulting in an incorrect cache.

To fix all of these issues, we now watch for NS_EVENT_STATE_READWRITE changes on the root element of the document.
Because we use the root element (not the body), this should avoid duplicate state changes for contentEditable changes on the body, which get handled by LocalAccessible::DOMAttributeChanged.

Finally, we previously fired only an editable state change, but changing the editable state of a document also impacts the read-only state.
This too resulted in an incorrect cache.
We now fire a read-only state change as well.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f9ccf06d514b
Fire correct state change events when designMode is changed on a document. r=eeejay

Comment 5

[Norisz Fay [:noriszfay]]

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