Closed Bug 402049 Opened 17 years ago Closed 16 years ago

ARIA tooltips triggering AT-SPI events with an invalid source

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: scott, Assigned: aaronlev)

References

(Blocks 1 open bug)

Details

(Keywords: access, Whiteboard: orca:normal)

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?
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.
See also bug 402597
Blocks: aria, fox3access
Keywords: access
Close as WFM for this bug, since Scott couldn't reproduce it. The invalid source issue is bug 402597.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
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
Whiteboard: orca:normal
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>.
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.
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.
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.
Scott, tomorrow (1/30), it would be good to get a status update on what's still broken in that build.
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?
I think they need to change their testcase if that's what they are doing. Are they at least using aria-hidden?
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.
aria-hidden plus display:none or visibility:hidden
Do we read "aria-hidden" in code of accessible module?
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
Closed: 17 years ago → 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.