GNOME Bugzilla – Bug 589726
Orca cannot handle all mouseover objects
Last modified: 2018-02-08 12:56:00 UTC
We recently added support in Orca so that users can access mouseover objects in Firefox content. There are so many different types of mouseover objects present that we could not hope to handle all cases in the initial implementation. Now that the initial implementation is committed and can be tested by the broader Orca community, I'm anticipating a few issues being reported. :-) Given that I will almost certainly be the one fixing those issues, I would like to temporarily bend our "one issue per bug report" rule. If you have a mouseover-related issue, for now, please add it as a comment to this bug. That way we can look for common issues and not be flooded with reports. Thanks!
Issue: Orca currently doesn't support nested mouseover objects Steps to reproduce: 1. Navigate to http://developer.yahoo.com/yui/examples/menu/leftnavfrommarkupwithanim_source.html 2. Tab to the Communication link. 3. Press Orca + KP_Divide to route the mouse pointer over Communication. 4. After Orca announces the new children, press Orca + KP_Multiply to move focus into the new object (which is, functionally, the Communication menu). 5. Tab until focus is on the PIM link. 6. Press Orca + KP_Divide to route the mouse pointer over PIM. 7. After Orca announces the new children, Press Orca + KP_Multiply to move focus into the new object (which is functionally the PIM submenu) Expected results: Focus would move to the first item in the PIM submenu. Actual results: The position of the mouse pointer is restored back to hovering over the Communication link. This causes the PIM submenu to no longer be visible. Solution (I think): We need to store not just the last coordinates and the last mouseover object, but a list of these things. We also need to add additional logic when setting the value of inMouseOverObject.
Issue: Sometimes hovering the mouse over an object results in multiple children being added. And Orca speaks 'em all. Steps to reproduce: 1. Follow steps 1-3 from the test case in Comment #1. Expected results: The top most object (section) would be presented. Actual results: We announce that the PIM link has been added, followed by the fact that a section has been added, followed by the fact that another section has been added. Solution: Not sure. I haven't yet figured out a way to identify reliably what (if anything) can be filtered out. Perhaps if the objects came from the top down rather than the bottom up, we could do something. Another possibility (which I have not pursued) might be to look at states. Maybe, for instance, the PIM link lacks STATE_VISIBLE or STATE_SHOWING or STATE_SENSITIVE or something until its parent container has been added. Maybe Gecko should be setting STATE_BUSY.... <shrugs> I'll give it some more thought.