786508 - Binding change due to CSS rule causes surplus incorrect accessibility focus event

Status: RESOLVED WONTFIX

(Core :: Disability Access APIs, defect)

Description

[aleth [:aleth]]

If a DOM element has a CSS rule that can change its XBL binding, and which is triggered in a situation where the element gains accessibility focus, two accessibility focus events are fired (rather than one) when this happens . 

The first event corresponds to the old binding and therefore refers to an accessible which dies before the screen reader has a chance to query it. It is superfluous and causes problems on screen readers (e.g. with NVDA, the reader annoyingly says "frame" every time).

This was reported for Instantbird in https://bugzilla.instantbird.org/show_bug.cgi?id=1626. There, a CSS rule of the form 

 contact {
   -moz-binding: url("chrome://instantbird/content/contact.xml#contact");
 }
 #aListbox:focus > contact[selected] {
   -moz-binding: url("chrome://instantbird/content/contact.xml#contact-big");
 }

changes the binding on "contact" elements (which extend richlistitems) in a richlistbox (#aListbox) when they become selected. NVDA says 'frame' whenever this happens.

It is (sometimes?) possible to workaround this by intercepting events which correspond to when the CSS rule will trigger (e.g. DOMAttrModified on the selected attribute on the richlistitem) and forcing the new binding to attach immediately (e.g. by calling element.getBoundingClientRect()), before the superfluous accessibility focus event fires. But this is really a hack as you have to cover all eventualities corresponding to the CSS rule, in effect duplicating that logic.

Comment 1

[alexander :surkov (:asurkov)]

it's similar to bug 686400 or bug 659886 (when those accessible were focused)

Comment 2

[aleth [:aleth]]

(In reply to aleth from comment #0)
> It is (sometimes?) possible to workaround this by intercepting events which
> correspond to when the CSS rule will trigger (e.g. DOMAttrModified on the
> selected attribute on the richlistitem) and forcing the new binding to
> attach immediately (e.g. by calling element.getBoundingClientRect()), before
> the superfluous accessibility focus event fires.

Note this workaround no longer works when using a MutationObserver instead of an event listener for the now deprecated DOMAttrModified.

Comment 3

[James Teh [:Jamie]]

I think this is also hitting the type list in the Applications section of the Firefox Options screen. The symptoms are certainly the same, including the id of the accessible changing after it gets focus.

Str:
1. Tools menu -> Options -> Applications.
2. Focus the list of types.
3. Press down arrow.
Expected: Just one (valid) focus event.
Actual: Two focus events as described in comment 0.

This makes working with this list extremely annoying for NVDA users.
NVDA issue ticket: http://community.nvda-project.org/ticket/4608

Comment 4

[James Teh [:Jamie]]

This is very possibly fixed now that bug 686400 is fixed. That said, XBL is going away and the issue Firefox Preferences case described in comment 3 got fixed by something else a while ago.