Closed Bug 1764500 Opened 3 years ago Closed 3 years ago

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

Categories

(Core :: Disability Access APIs, defect)

Desktop
Windows
defect

Tracking

()

RESOLVED FIXED
101 Branch
Tracking Status
firefox101 --- fixed

People

(Reporter: Jamie, Assigned: Jamie)

References

Details

(Whiteboard: [ctw-m2])

Attachments

(1 file)

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.

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.

See Also: → 1681735
See Also: → 1764739
Assignee: nobody → jteh

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.

Blocks: 1733188
Pushed by jteh@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/f9ccf06d514b Fire correct state change events when designMode is changed on a document. r=eeejay
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 101 Branch
Blocks: 1681735
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: