Unify platform event firing across local and remote Accessibles
Categories
(Core :: Disability Access APIs, task)
Tracking
()
Tracking | Status | |
---|---|---|
firefox117 | --- | fixed |
People
(Reporter: Jamie, Assigned: Jamie)
References
Details
(Whiteboard: [ctw-postship])
Attachments
(6 files, 1 obsolete file)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
Currently, local and remote events are handled very differently. For local, we use AccEvent. For remote, we have a bunch of Proxy*Event
methods. We want to be able to unify event handling for local and remote accessibles. To do this, AccEvent needs to hold an Accessible instead of a LocalAccessible.
Comment 1•4 years ago
|
||
Updated•4 years ago
|
Assignee | ||
Comment 2•2 years ago
|
||
When we get to cleaning up events, I wonder whether we should flip this around and instead use (and rename) the Proxy*Event methods and use them for everything. That is, platforms would never deal with AccEvent directly. Advantages:
- AccEvent won't contain a bunch of useless (and potentially confusing) members for remote events that are only useful for local events.
- We don't have to deal with the ref counting stuff.
- While we have AccessibleWrap, we have no equivalent for RemoteAccessible. We could move HandleAccEvent to Platform.h, but we already have these Proxy*Event functions, so we'd basically just end up calling the same functions or merging their code into one function.
To do this, we'd have LocalAccessible::HandleAccEvent call the new event firing functions as appropriate. The AccessibleWrap implementations could then be removed.
Eitan, thoughts?
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 4•2 years ago
|
||
Eitan, it looks like we still use vc events for things like caret movement and scrolling from content to parent. I assume that's no longer strictly necessary? That is, the only thing we really need vc events for now is hit testing (because that still gets routed via content).
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 5•2 years ago
|
||
Having discussed this with Eitan, it looks like we can indeed clean up the Android VC event usage, but let's do this in a future bug.
Assignee | ||
Comment 6•2 years ago
|
||
This was done with the following command in the accessible/ directory:
sed -i 's/\bProxy\(.*\)Event\b/Platform\1Event/' `git grep -l 'Proxy.*Event'`
Assignee | ||
Comment 7•2 years ago
|
||
Some of these methods don't yet handle LocalAccessible properly, but that will be fixed in subsequent patches.
Assignee | ||
Comment 8•2 years ago
|
||
This takes an Accessible and a rect and calls the local or remote versions appropriately.
This avoids the duplication of conditional behaviour in PlatformFocusEvent and PlatformCaretMoveEvent.
Assignee | ||
Comment 9•2 years ago
|
||
TextRangeData is specific to IPDL and thus RemoteAccessible.
Assignee | ||
Comment 10•2 years ago
|
||
Mac and Android still override HandleAccEvent for platform specific behaviour other than firing the event.
The Android behaviour can be unified properly in future work.
ATK is the platform layer with the most churn because there were inconsistencies in the way local and remote events were handled.
I'm reasonably sure these were unintentional inconsistencies, so I've done my best to unify them.
Assignee | ||
Comment 11•2 years ago
|
||
Comment 12•2 years ago
|
||
Comment 13•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/152a5f01d443
https://hg.mozilla.org/mozilla-central/rev/060942e1d31f
https://hg.mozilla.org/mozilla-central/rev/56aae90925f8
https://hg.mozilla.org/mozilla-central/rev/54d3449fca3c
https://hg.mozilla.org/mozilla-central/rev/b59caf87b3b2
https://hg.mozilla.org/mozilla-central/rev/2f270a08993b
https://hg.mozilla.org/mozilla-central/rev/4f35a86f6d3c
Description
•