The default bug view has changed. See this FAQ.

ARIA tooltips triggering AT-SPI events with an invalid source

RESOLVED WORKSFORME

Status

()

Core
Disability Access APIs
RESOLVED WORKSFORME
10 years ago
8 years ago

People

(Reporter: Scott Haeger, Assigned: Aaron Leventhal)

Tracking

(Blocks: 1 bug, {access})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: orca:normal)

(Reporter)

Description

10 years ago
The Mozilla example tooltip seen here http://www.mozilla.org/access/dhtml/new/tooltip.html seems fine.  However, the dojo tooltip examples seen here http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/test_Tooltip.html start off fine, but repeated activation and perhaps moving focus away from Firefox causes an explosion of events to be triggered.  Most of the events are object:children-changed:add and object:property-change:accessible-parent events.

This may prove to be a dojo bug, I am not sure.  I figured this was a good place to start to resolve this issue.
Explosions of events are not that uncommon in A11y land. Scott do you know if Orca has a strategy for filtering this explosion successfully?
(Reporter)

Comment 2

10 years ago
The explosion of events that I indicate is not simply a series of events of different types.  I was referring to a series of repeated events of the same type on the same object -- clearly an error.  However, no matter how hard I try I cannot seem to reproduce the problem I saw yesterday.  

The following is an event log looking only at object: events on a single tooltip event.  The second event shows an invalid source which is one error I indicated yesterday in IRC.

object:text-changed:delete:system(95, 1, )
	source: [document frame | Dojo Tooltip Widget Test]
	application: [application | Minefield]
object:text-changed:insert:system(0, 19, tooltip on a button)
	source: [invalid | ]
	application: [application | Minefield]
object:children-changed:remove:system(22, 0, None)
	source: [document frame | Dojo Tooltip Widget Test]
	application: [application | Minefield]
object:text-changed:insert:system(95, 1, )
	source: [document frame | Dojo Tooltip Widget Test]
	application: [application | Minefield]
object:children-changed:add:system(22, 0, None)
	source: [document frame | Dojo Tooltip Widget Test]
	application: [application | Minefield]


> Does Orca have a strategy for filtering out an explosion of events?
Orca looks for particular events and acts upon them.  So if the explosion of events is of different event types there is no problem.  The problems occur when we get repeated events of the same type on the same object.  I do not believe there are any safe guards for this situation.
(Assignee)

Comment 3

10 years ago
See also bug 402597
Blocks: 343213, 396346
Keywords: access

Comment 4

9 years ago
Close as WFM for this bug, since Scott couldn't reproduce it.

The invalid source issue is bug 402597.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 5

9 years ago
This bug should address the invalid source in the object:text-changed:insert:system event as seen in comment #2.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Summary: ARIA tooltips triggering many repeated AT-SPI events → ARIA tooltips triggering AT-SPI events with an invalid source

Updated

9 years ago
Whiteboard: orca:normal
(Reporter)

Comment 6

9 years ago
This tooltip http://www.mozilla.org/access/dhtml/new/tooltip.html is now triggering a single text-changed event on the <p>, which is incorrect.  I would expect both a text-changed and a children-changed event.  Changing the <span> (the tooltip) to a <p> corrects the event sequence.  Also, any_data on the children-changed event is correct with this change.  see also bug #395699 - relations not working when pointing to a <span>.
(Reporter)

Comment 7

9 years ago
no text-changed or children-changed events for this one http://test.cita.uiuc.edu/aria/tooltip/view_inline.php?title=Tooltip%20Example%201&ginc=includes/tooltip1_inline.inc&gcss=css/tooltip1_inline.css&gjs=js/tooltip1_inline.js,../js/widgets_inline.js,../js/globals.js where the tooltip is a <div>
(Reporter)

Comment 8

9 years ago
On second look, The http://www.mozilla.org/access/dhtml/new/tooltip.html tooltip is sending both a text-changed and children-changed events.  The problem is any_data in None for the children-changed event.
(Reporter)

Comment 9

9 years ago
A similar problem can be seen for the first combobox see here http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_ComboBox.html .  When the list opens, any_data is None for the children-changed event.

Comment 10

9 years ago
In this bug's comments, several different issues were reported. That's a bad practice.

comment #2 is a similar issue of bug 413777.
In dojo.js, it sets InnerHTML, it will cause nsDocAccessible::InvalidateCacheSubtree for EVENT_DOM_DESTROY.
So the source object of text-changed event is recreated, right after the event was emitted.

comment #8, comment #9 is bug 402597.

testcase in comment #7 uses aria-hidden to control tooltip.
state-changed event is expected, I think we didn't implement it yet.

I suggest we file separate bug for separate issues  and close this one.
(Assignee)

Comment 11

9 years ago
Scott, tomorrow (1/30), it would be good to get a status update on what's still broken in that build.

Comment 12

9 years ago
For the testcase in comment #7,
the visibility of tooltip is controlled by style.left, style.top.
In http://test.cita.uiuc.edu/aria/tooltip/js/tooltip1_inline.js ,
it just sets the style.left, style.top to -200em and -20em to make it disappear.

frame->GetStyleVisibility()->IsVisible() will return TRUE in this case.
So the accessible objects for the tooltips are always created.

Should we track the position change?
(Assignee)

Comment 13

9 years ago
I think they need to change their testcase if that's what they are doing. Are they at least using aria-hidden?
(Reporter)

Comment 14

9 years ago
The Mozilla tooltip and Dojo combobox are much better.  I am getting good events with correct source and any_data.  Great work!  I'll test more today.

I agree with Aaron on the UIUC tooltip test case.  It needs to be updated to use aria-hidden.  I will drop Jon a note. 
(Assignee)

Comment 15

9 years ago
aria-hidden plus display:none or visibility:hidden

Comment 16

9 years ago
Do we read "aria-hidden" in code of accessible module?
(Assignee)

Comment 17

9 years ago
No, we don't need to. It's the author's responsibility to attach that to a visibility/display style. As long as the element actually becomes hidden or visisble, we'll trigger off that. It's better to look at the reality of whether something is hidden or not.
I recommend closing based on comment #14. This one feels stale.
Clossing as WFM as per recommendation from David in comment #18 and the info in comment #14.
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.