Last Comment Bug 402049 - ARIA tooltips triggering AT-SPI events with an invalid source
: ARIA tooltips triggering AT-SPI events with an invalid source
: access
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: unspecified
: x86 Linux
-- normal (vote)
: ---
Assigned To: Aaron Leventhal
: alexander :surkov
Depends on:
Blocks: aria fox3access
  Show dependency treegraph
Reported: 2007-11-01 07:51 PDT by Scott Haeger
Modified: 2008-12-18 22:09 PST (History)
5 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Scott Haeger 2007-11-01 07:51:13 PDT
The Mozilla example tooltip seen here seems fine.  However, the dojo tooltip examples seen here 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.
Comment 1 User image David Bolter [:davidb] 2007-11-01 09:24:56 PDT
Explosions of events are not that uncommon in A11y land. Scott do you know if Orca has a strategy for filtering this explosion successfully?
Comment 2 User image Scott Haeger 2007-11-01 09:57:25 PDT
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.
Comment 3 User image Aaron Leventhal 2007-11-15 13:58:35 PST
See also bug 402597
Comment 4 User image Ginn Chen 2007-12-11 03:16:50 PST
Close as WFM for this bug, since Scott couldn't reproduce it.

The invalid source issue is bug 402597.
Comment 5 User image Scott Haeger 2007-12-11 06:31:07 PST
This bug should address the invalid source in the object:text-changed:insert:system event as seen in comment #2.
Comment 6 User image Scott Haeger 2008-01-28 07:00:55 PST
This tooltip 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>.
Comment 8 User image Scott Haeger 2008-01-28 08:26:53 PST
On second look, The tooltip is sending both a text-changed and children-changed events.  The problem is any_data in None for the children-changed event.
Comment 9 User image Scott Haeger 2008-01-28 08:28:38 PST
A similar problem can be seen for the first combobox see here .  When the list opens, any_data is None for the children-changed event.
Comment 10 User image Ginn Chen 2008-01-29 03:59:54 PST
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.
Comment 11 User image Aaron Leventhal 2008-01-29 19:09:12 PST
Scott, tomorrow (1/30), it would be good to get a status update on what's still broken in that build.
Comment 12 User image Ginn Chen 2008-01-30 03:50:29 PST
For the testcase in comment #7,
the visibility of tooltip is controlled by style.left,
In ,
it just sets the style.left, 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?
Comment 13 User image Aaron Leventhal 2008-01-30 04:05:38 PST
I think they need to change their testcase if that's what they are doing. Are they at least using aria-hidden?
Comment 14 User image Scott Haeger 2008-01-30 07:07:26 PST
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. 
Comment 15 User image Aaron Leventhal 2008-01-30 07:16:02 PST
aria-hidden plus display:none or visibility:hidden
Comment 16 User image Ginn Chen 2008-01-30 19:33:13 PST
Do we read "aria-hidden" in code of accessible module?
Comment 17 User image Aaron Leventhal 2008-01-30 19:53:46 PST
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.
Comment 18 User image David Bolter [:davidb] 2008-12-18 16:59:52 PST
I recommend closing based on comment #14. This one feels stale.
Comment 19 User image Marco Zehe (:MarcoZ) 2008-12-18 22:09:56 PST
Clossing as WFM as per recommendation from David in comment #18 and the info in comment #14.

Note You need to log in before you can comment on or make changes to this bug.