Closed Bug 686400 Opened 8 years ago Closed 4 months ago

Figure out how to tell whether a reframe actually changes what's shown on the screen

Categories

(Core :: Disability Access APIs, defect, P2)

x86
macOS
defect

Tracking

()

RESOLVED FIXED
mozilla70
Tracking Status
firefox70 --- fixed

People

(Reporter: ehsan, Assigned: eeejay)

References

(Blocks 1 open bug, Regressed 1 open bug)

Details

(Keywords: access)

Attachments

(3 files)

In layout, we reframe every time that something happens which could potentially change the rendering of an element on the screen.  The reframe is performed by pretending that the node has been removed from the DOM, and inserted back into the same position.  These reframes cause unneeded accessibility notifications in the cases where the rendered content doesn't change on the screen (for example, when the overflow style changes for most types of inline frames, see bug 606087), but is that change requires any visual change to any frame type on the screen, then we cannot avoid reframing (see bug 686247 as an example).

We need to figure out a way to allow layout to work correctly, but also let a11y figure out which content insertion/removal pairs it can ignore.
Another example of unnecessary accessible tree update due to frame recreation is bug 395900.
Blocks: 395900
Keywords: access
one more example we've seen in bug 733848 where images were recreated after insertion into the tree (it seems they were recreated without any good reason). Logging didn't helped there, stacks weren't captured, debug builds never failed.
remove a workaround introduced in bug 733848 when this bug is fixed
Blocks: 733848
CC+ Trevor, because this could interest him.
Depends on: 1068291
Blocks: 1068291
No longer depends on: 1068291
Blocks: 1256706
Assignee: nobody → eitan

We naively remove and then recreate accessibles when their content's
frame is reconstructed. By delaying the removal until we are certain the
content does not have a new layout frame, we can cut down on redundant
recreations.

Attachment #9078814 - Attachment description: Bug 686400 - Delay accessible removal on frame reconstruction. r?Jamie! → Bug 686400 - Delay accessible removal on frame reconstruction. r?Jamie! r?emilio
Attachment #9078814 - Attachment description: Bug 686400 - Delay accessible removal on frame reconstruction. r?Jamie! r?emilio → Bug 686400 - Delay accessible removal on frame reconstruction. r?Jamie!,emilio!

It seems a bit more sensible to me that if ny filtering needs to happen
from content insertions, it should happen in the doc and not the
notification controller.

Depends on D40131

Priority: -- → P2
Pushed by eisaacson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/749582be170c
Add function to nsCoreUtils for display: contents. r=Jamie
https://hg.mozilla.org/integration/autoland/rev/9c430a684fe0
Filter content insertions in DocAccessible. r=Jamie
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70

Not fixed yet; first two patches landed but third hasn't.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Pushed by eisaacson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/06d909e0de08
Delay accessible removal on frame reconstruction. r=Jamie,emilio
Status: REOPENED → RESOLVED
Closed: 4 months ago4 months ago
Resolution: --- → FIXED
Regressions: 1571232
Regressions: 1571616
No longer regressions: 1571232
Regressions: 1572317
Regressions: 1572490
Regressions: 1572811
Regressed by: 1572829
Regressions: 1572851
No longer regressed by: 1572829
Regressions: 1572829
Depends on: 1576690
Blocks: 1346788
Regressions: 1592518
Regressions: 1597916
No longer regressions: 1597916
You need to log in before you can comment on or make changes to this bug.