432603 - Click action broken on most element types

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

[James Teh [:Jamie]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008050606 Minefield/3.0pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008050606 Minefield/3.0pre

When an onClick event attribute is set for an element, Gecko exposes a "click" action to accessibility APIs. However, attempting to activate this "click" action fails on most element types, including graphics, spans and paragraphs. It does work correctly on table cells and links, triggering the appropriate action. (Note that in the case of links, the action is incorrectly exposed as "jump", even though the onClick event should override this and cause it to be "click". However, this is inconsequential and outside the scope of this report.)

Reproducible: Always

Steps to Reproduce:
1. Load the test case provided.
2. Using NVDA or JAWS, move the virtual cursor to the clickable graphic.
3. Press enter to activate the graphic.
4. Repeat steps 2 and 3 for the clickable span.
Actual Results:  
Pressing enter does not cause the onClick action to be triggered.

Expected Results:  
When activated, the appropriate action should be taken as defined by the onClick action.

When this fails, an unspecified COM exception occurs.

Comment 1

[James Teh [:Jamie]]

Attachment: Test case.

This sample provides a clickable image, span, link and table cell. The clickable image and span cannot be activated using accessibility APIs. Conversely, the link and table cell can be activated.

Comment 2

[Michael Curran]

IAccessible::accDoDefaultAction() and IAccessibleAction::doAction(0) are both returning E_FAIL for the test cases.
Note that it is possible to do IAccessible::accDefaultAction, or  queryInterface to IAccessibleAction, and do IAccessibleAction::name(0) which returns 'click' for the image and span.
This would seem then that the problem is most likely somewhere in
NSIAccessible::DoAction.
Is it possible for someone with a debug build to see if a timer for DoCommandCallback has already been registered when DoAction is called? thats about the only thing I can see that would make DoAction ... or DoCommand return fail.

Comment 3

[alexander :surkov (:asurkov)]

possibly it's a part of patch of the bug 410765.

related bugs are bug 363697, bug 405990, bug 410765, bug 404576.

Comment 4

[Marco Zehe (:MarcoZ)]

Nominating for blocking, since this means that clickable elements can currently not be activated by blind users.

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

What's the regression range? Marco, you and Alexander are the only ones who have been touching that code recently, so do you know what might have caused this?

Comment 6

[Mike Schroepfer]

Marco/Alexander we are otherwise locked down for RC1 - can this wait for 3.0.1 and/or if it is a showstopper we'll need a fix asap.

Comment 7

[Mike Connor [:mconnor]]

So, I don't think this is a regression, and I don't think this is a common thing on the web.  There's clearly some cases where this sucks, but unless we broke this since Firefox 2, there's no way this blocks, IMO.

Comment 8

[Mike Schroepfer]

Yea agreed - let's get this fixed in 3.0.1

Comment 9

[James Teh [:Jamie]]

Test case works for me in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080925033548 Minefield/3.1b1pre ID:20080925033548
This was perhaps fixed by bug 410765 or bug 449717.

Comment 10

[alexander :surkov (:asurkov)]

Marco or James could please check bugs mentioned in comment #3? They are possibly fixed as well.