1681735 - Google keep top-level document should not have the accessible "editable" state

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

[Joanmarie Diggs]

Attachment: is-editable.py (accessible event listener)

Steps to reproduce:
0. Launch the attached accessible-event listener in a terminal

1. Navigate to https://keep.google.com/#home (you should already be signed in)
2. Focus should automatically be in the "Take a note..." input
3. Cause the document to gain focus (e.g. by tabbing several times from the address bar)

Expected results: The listener would indicate the document is not editable

Actual results: The listener indicates the document is editable

Notes:

1. If the listener indicates the document is not editable, try reloading the page (do not quit the listener first).
2. Having confirmed the bug, leave focus on the document, quit the listener, restart the listener, and alt+tab back into the firefox window. Now the listener should indicate the document is not editable. The reason for this is presumably because at some point the accessible editable state is removed from the document BUT not object:state-changed:editable event is emitted. Thus AT-SPI2 doesn't update its state set.

Impact: Orca thinks that descendants of the entire web page are part of contenteditable content and totally changes its behavior based on that.

Comment 1

[James Teh [:Jamie]]

I wasn't able to reproduce this on Windows, but NVDA might just be getting to the document slightly later than Orca does.

Some brief initial testing did seem to indicate that we aren't firing a stateChange event for the document when contentEditable changes on the body, which is odd because we do fire it for other nodes and I can't see why the document should be any different.

Another question is whether we're dealing with contentEditable or designMode here. We probably don't fire events for designMode changes; at least, I didn't see where we would from a brief look at the code.

Comment 2

[James Teh [:Jamie]]

Eitan, would you mind testing whether this still happens? I suspect it was fixed by bug 1764500.

Comment 3

[James Teh [:Jamie]]

I tested this myself. The listener now always reports that the document is not editable. This was likely fixed by bug 1764500.

Comment 4

[Eitan Isaacson [:eeejay]]

Getting to this very late, and I can't reproduce either. FWIW, we the document focuses once it loads and the script suggests it is not editable.