Bug 135689 - AX: event.target should sometimes be a descendant element on AXPress-triggered mouse clicks
Summary: AX: event.target should sometimes be a descendant element on AXPress-triggere...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Accessibility (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: chris fleizach
URL:
Keywords: InRadar
Depends on: 131426
Blocks:
  Show dependency treegraph
 
Reported: 2014-08-06 22:26 PDT by James Craig
Modified: 2014-12-18 14:59 PST (History)
11 users (show)

See Also:


Attachments
test case (736 bytes, text/html)
2014-08-06 23:26 PDT, James Craig
no flags Details
updated test case (1.68 KB, text/html)
2014-08-07 00:26 PDT, James Craig
no flags Details
patch (4.94 KB, patch)
2014-12-15 23:54 PST, chris fleizach
mario: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description James Craig 2014-08-06 22:26:01 PDT
AXPress sometimes triggers the click event (and other mouse events) on a different element than a real mouse click would use. We should try using hit-testing at the center of the clickable (link, button, etc.) to determine the element on which to initiate the mouse events. In some cases, it may be better to a descendant node as the event.target. If the center point hit-test results in a node that is not a descendant, we should ignore it and fire the event on the original element.

To be clear, I don’t think WebKit is doing anything wrong, but there are times when web authors do silly things. VO+Space doesn’t work, but routing the mouse to an element and triggering a simulated mouse click does. This idea is mainly to work around those web authoring problems, and make it so that AXPress works in more scenarios.
Comment 1 Radar WebKit Bug Importer 2014-08-06 22:26:17 PDT
<rdar://problem/17941920>
Comment 2 James Craig 2014-08-06 23:15:10 PDT
Looks like at least part of this was done in bug 131426. I'll try to attach a test case where it doesn't work.
Comment 3 James Craig 2014-08-06 23:26:49 PDT
Created attachment 236174 [details]
test case
Comment 4 James Craig 2014-08-06 23:28:36 PDT
In the attached test case, the second clickable element (image inside button) is trigger by AXPress, but the first clickable element (span inside link) is only clickable with the mouse, not AXPress.
Comment 5 James Craig 2014-08-07 00:26:51 PDT
Created attachment 236176 [details]
updated test case

updated test case logs the event target and includes some failure cases to ensure we don't click things that are positioned over the top of the element in the VO cursor.
Comment 6 James Craig 2014-08-08 11:25:48 PDT
Might need to ignore any child that does not accept pointer events via CSS. See bug 11395 and Dean's write-up: http://www.webkit.org/specs/PointerEventsProperty.html
Comment 7 chris fleizach 2014-12-15 23:54:39 PST
Created attachment 243353 [details]
patch
Comment 8 chris fleizach 2014-12-15 23:55:35 PST
Note: I did not cover the cases in your original test case about the intercepting view. We have code specifically to fall back to the original element if we hit-test to a non-descendant. I'm worried about removing that code.
Comment 9 Mario Sanchez Prada 2014-12-18 13:21:04 PST
Comment on attachment 243353 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=243353&action=review

> LayoutTests/accessibility/press-target-uses-text-descendant-node.html:21
> +     .target {
> +         background-color: yellow;
> +      }

Nit: this looks misaligned
Comment 10 chris fleizach 2014-12-18 14:59:41 PST
http://trac.webkit.org/changeset/177532