Open Bug 1015379 Opened 10 years ago Updated 2 years ago

LinkableAccessible::DoAction Does not correctly simulate mouse click

Categories

(Core :: Disability Access APIs, defect)

defect

Tracking

()

People

(Reporter: eeejay, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

Attachments

(2 files)

Attached file Test case
Very large lists, like the contact list in fxos have a single click listener on the parent list. I think this helps with performance during load time, when a listener does not need to be attached to each list item.

The event handler could then act on the target li.

Currently, performing doAction() on a text leaf will not yield the appropriate result, for two reasons:
1. The coordinate where click is performed is in the center of the entire list, and not the text leaf.
2. The synthesized click event's target is explicitly set to be the listener (in this case of parent list).
I don't follow 2nd because all we do we send a mouse click, no? Concerning to 1st are you saying the item should be auto scrolled into view before click?
Blocks: actiona11y
(In reply to alexander :surkov from comment #1)
> I don't follow 2nd because all we do we send a mouse click, no? Concerning
> to 1st are you saying the item should be auto scrolled into view before
> click?

No.

Load the test case.

With no a11y, if you click the word 'Card', you will see a blue dot on the word, and the parent <li> will turn pink (and get a class of 'selected').

Now with the a11y API, if you run the snippet below in a browser scratchpad, you will get a blue dot in the center of the entire list, and the "Adam Card" item won't be selected. You should get the same result as the direct method.

Cc["@mozilla.org/accessibleRetrieval;1"].getService(Ci.nsIAccessibleRetrieval)
  .getAccessibleFor(content.document.querySelector('li')).lastChild.doAction(0);
Note, that I tried simply adjusting the coordinates to be the center of the text leaf, but that doesn't help, because the "click" event is sent with the list being the target.
ah I see, so the point is event target is not what you expected. Did you try to debug it?
(In reply to alexander :surkov from comment #4)
> ah I see, so the point is event target is not what you expected. Did you try
> to debug it?

Yeah, we force the target to the DOMNode of the accessible via HandleEventWithTarget instead of allowing the content to do its own hit testing.

I think the targetting issue should be a separate bug, because it is not related to the LinkableAccessible behavior. Filing now..
Depends on: 1017322
No longer depends on: 1017322
Depends on: 1017322
This depends on the patch in bug 1017322.
Attachment #8431213 - Flags: feedback?(surkov.alexander)
Comment on attachment 8431213 [details] [diff] [review]
LinkableAccessible::DoAction should use accessible's content for click.

Review of attachment 8431213 [details] [diff] [review]:
-----------------------------------------------------------------

::: accessible/src/generic/BaseAccessibles.cpp
@@ +142,5 @@
>    if (aIndex != eAction_Jump)
>      return NS_ERROR_INVALID_ARG;
>  
> +  if (mActionAcc) {
> +    mActionAcc->DoCommand(mContent, aIndex);

it's something strange, one difference I see is DoAction on action accessible may do nothing however it can be invoked via its child. Can you comment taken approach please?
Attachment #8431213 - Flags: feedback?(surkov.alexander)
(In reply to alexander :surkov from comment #7)
> it's something strange, one difference I see is DoAction on action
> accessible may do nothing however it can be invoked via its child. Can you
> comment taken approach please?

You mean when the parent's actionCount is 0? We could check for that and return NS_ERROR_NOT_IMPLEMENTED. The one place that I see a problem is when the parent accessible's DoAction does TakeFocus instead of a click.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: