Don't recreate accessibles if reframing doesn't cause a change in accessible type

NEW
Unassigned

Status

()

P3
normal
3 years ago
a month ago

People

(Reporter: MarcoZ, Unassigned)

Tracking

(Blocks: 3 bugs)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox50 affected)

Details

(Reporter)

Description

3 years ago
Spun off bug 1256706. Twitter used to do a CSS change from position:absolute; to position:relative; when focus changed from one tweet to the next, see bug 1256706 comment #4 and dholbert's analysis in bug 1256706 comment #5.

Implement a solution on the accessibility APIs side as suggested in bug 1256706 comment #7:
> Also we could try to make the accessible tree updates smarter, like if a
> frame type of a DOM node wasn't changed during frames reconstruction then no
> accessible update should be required. This check shouldn't be very expensive.

Alex, you also said you had a prototype working. Could you finish this on this bug?
Flags: needinfo?(surkov.alexander)
(Reporter)

Updated

3 years ago
Blocks: 1277201
(In reply to Marco Zehe (:MarcoZ) from comment #0)

> Alex, you also said you had a prototype working. Could you finish this on
> this bug?

thanks for filing it, I'll see what I can do
Flags: needinfo?(surkov.alexander)
Priority: -- → P3
let's move this one out off the backlog, it should be considered to be fixed asap.
Priority: P3 → P2
Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.