Closed Bug 348621 Opened 15 years ago Closed 15 years ago
Contents of <iframe> not firing valid accessibility events
Steps: Load a document with an iframe, such as http://www.mozilla.org/access/samples/js-nsIAccessible.htm With an accessibility testing tool open, tab until you get to the iframe contents. Accessibility events are fired, but the role, state and other info are not available for the event targets.
aaron, which at event tool you use?
(In reply to comment #3) > aaron, which at event tool you use? MSAA Inspect will work, or a combination of that and MSAA event watcher. But, I think the same problem would show up if watching the events on Linux using at-poke.
1-25 works 1-26 broken
Sorry, forgot to say the regression was in 2006. 1-25-2006 works 1-26-2006 broken
The domNode in PresShell::HandleEventInternal() is for the root html doc instead of the iframe doc. Not sure why yet, because the HWND we use with NotifyWinEvent() is for the correct window.
Assignee: nian.liu → aaronleventhal
I think it's bug 317375, which is probably changing how NS_ACCESSIBLE_EVENT is being targeted. That's the most likely thing from the checkins in the regression range: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-01-25+01%3A00%3A00&maxdate=2006-01-26+14%3A00%3A00&cvsroot=%2Fcvsroot
Robert, this was a regression from your patch to bug 317375.
Comment on attachment 261718 [details] [diff] [review] One line patch for regression. Don't treat NS_ACCESSIBLE_EVENT like a mouse event. Probably better to get 2 eyes on this given how long ago bug 317375 was checked in, and how complex it was. I wonder if we need to change any other similar places.
Attachment #261718 - Flags: superreview?(roc) → superreview?(dbaron)
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.