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

Status: RESOLVED FIXED

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

Description

[(no longer active)]

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.

Comment 1

[alexander :surkov (:asurkov)]

Another example of unnecessary accessible tree update due to frame recreation is bug 395900.

Comment 2

[alexander :surkov (:asurkov)]

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.

Comment 3

[alexander :surkov (:asurkov)]

remove a workaround introduced in bug 733848 when this bug is fixed

Comment 4

[David Bolter [:davidb] (NeedInfo me for attention)]

CC+ Trevor, because this could interest him.

Comment 5

[Eitan Isaacson [:eeejay]]

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

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.

Comment 6

[Eitan Isaacson [:eeejay]]

Attachment: Bug 686400 - Add function to nsCoreUtils for display: contents. r?Jamie!

Comment 7

[Eitan Isaacson [:eeejay]]

Attachment: Bug 686400 - Filter content insertions in DocAccessible. r?Jamie!

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

Comment 8

[Pulsebot]

Pushed by [e-mail]:
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

Comment 9

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/749582be170c
https://hg.mozilla.org/mozilla-central/rev/9c430a684fe0

Comment 10

[James Teh [:Jamie]]

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

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/06d909e0de08
Delay accessible removal on frame reconstruction. r=Jamie,emilio

Comment 12

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/06d909e0de08