606112 - Accessibility viewers suffer from potential observer effects

Status: RESOLVED INCOMPLETE

(Other Applications :: DOM Inspector, defect)

Description

[Colby Russell :crussell (no longer Mozilla-ing)]

Right now, there are some hacks in place in the accessibility viewers to pass multi-values from the viewer in the document pane to the viewer in the object pane.

Case study:
The Accessibility Events viewer tracks accessible events that occur in the inspected document.  When an event occurs, the user can select it in the tree, and the object viewer reacts accordingly, e.g., when the object viewer has the Accessible Event viewer active, it can display information about the event.  It's useful, however, to be able to use the DOM Node viewer to inspect the DOM node that the event occurred for.  There's the dilemma.  The DOM Node viewer only knows about DOM Nodes, while the Accessible Events viewer needs to be able to communicate more than just the DOM Node the event occurred for (e.g., the Accessible Event viewer needs it to pass the event).

The way this is currently accomplished is by passing (from the Accessible Events viewer) the DOM node for the document viewer's subject, *and* setting some arbitrary properties on the DOM Node: " accessible " for the nsIAccessNode and " accessible event " for the event.  Since these properties are set directly on the DOM node, these can be seen by content.

There are a few ways I can think of to achieve this without observer effects, some of which I already mentioned in bug 553364.

1. Just fix the DOM Nodes viewer, etc. to accept nsIAccessibleEvents, and obtain the DOM node from there.

2. Change the viewer contract so instead of giving one "selection" object, it would give a list of potential objects.  Items further down in the list would be fallbacks.  E.g., the first element could be the accessible event, with the second element being the DOM node.  Initially I favored this one, but not so much anymore.

3. Panels already have a "params" property, which is currently only used by the dom viewer.  The Accessible Events viewer could use the DOM node as its selection object, and it could put the events and other data in the params of the linked object panel, which would be checked by the Accessible Event viewer.

4. It's trivial for the object viewer to get a reference to the document viewer.  It shouldn't be too difficult for the Accessible Event viewer to call some method of the Accessible Events viewer when a subject change occurs, in order to get the event data.

Comment 1

[Colby Russell :crussell (no longer Mozilla-ing)]

Now that we have WeakMaps, we should be able to replace stuff like this:

> +      subject[" accessible "] = object.accessnode;

with

> accessiblesWeakMap.set(subject, object.accessnode);

The only problem is that there are no WeakWaps for versions < 6.  surkov, would it inconvenience anyone working in a11y (or anyone else, I guess) if we dropped support for the accessibility viewers in Firefox 5/SeaMonkey 2.2 and below?

Comment 2

[alexander :surkov (:asurkov)]

(In reply to Colby Russell :crussell from comment #1)

> The only problem is that there are no WeakWaps for versions < 6.  surkov,
> would it inconvenience anyone working in a11y (or anyone else, I guess) if
> we dropped support for the accessibility viewers in Firefox 5/SeaMonkey 2.2
> and below?

I'd say nobody cares if you're going to bump the supported lower version of Firefox/Toolkit in install.rdf. Otherwise it leads to confusion of those who uses it. I don't have any data about DOMi users so I can't say how many users are affected. You may turn this into evangelism problem and document this feature for ongoing release. But I'm inclined to think that the right way is to bump the version, at least it sounds like usual practice for extensions. In either way users loose something, either new DOMi features or accessibility inspection capabilities on old Firefox releases.

Comment 3

[Firefox Bug Husbandry Bot]

Bulk close. This component is no longer supported or maintained.

https://bugzilla.mozilla.org/show_bug.cgi?id=1499023

Comment 4

[Firefox Bug Husbandry Bot]

Bulk close. This component is no longer supported or maintained.

https://bugzilla.mozilla.org/show_bug.cgi?id=1499023