Implement caching asynchronous accessibility hit testing.

Implement caching asynchronous accessibility hit testing.

Native accessibility APIs all have some sort of "hit test"
function. Unfortunately on Mac, Windows, and Linux, they're all
synchronous APIs. This is problematic for Chrome because only
the render process can do an accurate hit test.

Previously we relied on an approximate hit test based on
accessible bounding boxes in the browser process. This was
okay for debugging, but not for users with low-vision who want
the accessible cursor to follow the mouse accurately.

To fix it, every time we get a hit test request we send an
asynchronous message to do an accurate hit test. While waiting,
we return an approximate hit test result instead. The next time
the mouse moves, if it's within the bounds of the object found
by the asynchronous hit test, we return that.

In practice it works well - as you mouse over an object, the
first pixel you cross will occasionally return the wrong object,
but one or two pixels later the correct object has been returned
by Blink and then it's correct.

Includes a test that confirms this behavior, that calling the
hit test first returns an approximate result and then later
returns the correct result if you call it repeatedly.

BUG=652996
Committed: https://crrev.com/e7ca9f46f8f281febb2762ce693b7f8d93e25f9e
Cr-Commit-Position: refs/heads/master@{#424521}

[dmazzoni, 2016-10-05 07:51:03]

dmazzoni@chromium.org changed reviewers:
+ aboxhall@chromium.org

[dmazzoni, 2016-10-05 16:49:59]

dmazzoni@chromium.org changed reviewers:
+ ellyjones@chromium.org

[dmazzoni, 2016-10-05 16:49:59]

+ellyjones

Actually Elly, this might be a good one for you to review too.

[Elly Fong-Jones, 2016-10-06 14:20:53]

lgtm

I really like this.

I wonder if it would be good to add a histogram so we know what the hit rate is
for this cache? It's not inconceivable that we'd get good/better results with a
cache that holds several elements instead of just one, but this way is
definitely simpler to start.

https://codereview.chromium.org/2393123002/diff/1/content/browser/accessibili...
File content/browser/accessibility/browser_accessibility_cocoa.mm (right):

https://codereview.chromium.org/2393123002/diff/1/content/browser/accessibili...
content/browser/accessibility/browser_accessibility_cocoa.mm:2854: LOG(ERROR) <<
"HitTest " << point.x << ", " << point.y
leftover?

[dmazzoni, 2016-10-10 19:36:42]

On 2016/10/06 14:20:53, Elly Fong-Jones wrote:
> lgtm
> 
> I really like this.
> 
> I wonder if it would be good to add a histogram so we know what the hit rate
is
> for this cache? It's not inconceivable that we'd get good/better results with
a
> cache that holds several elements instead of just one, but this way is
> definitely simpler to start.

One nice property is that for simple webpages it doesn't really matter because
the default
hit testing already works fine.

When the layout is more complex, the cache misses happen every time you leave
the bounds
of an object.

I'm not sure how we could really cache more in a way that'd be useful. Would we
cache
the mapping between all adjacent pixels to the current one? I'm worried the
cache could
quickly grow large with no clear benefit.

[dmazzoni, 2016-10-10 19:36:42]

https://codereview.chromium.org/2393123002/diff/1/content/browser/accessibili...
File content/browser/accessibility/browser_accessibility_cocoa.mm (right):

https://codereview.chromium.org/2393123002/diff/1/content/browser/accessibili...
content/browser/accessibility/browser_accessibility_cocoa.mm:2854: LOG(ERROR) <<
"HitTest " << point.x << ", " << point.y
On 2016/10/06 14:20:53, Elly Fong-Jones wrote:
> leftover?

Fixed

[dmazzoni, 2016-10-10 19:36:47]

The CQ bit was checked by dmazzoni@chromium.org

[dmazzoni, 2016-10-10 19:36:48]

The patchset sent to the CQ was uploaded after l-g-t-m from
ellyjones@chromium.org
Link to the patchset: https://codereview.chromium.org/2393123002/#ps20001
(title: "Remove log")

[commit-bot: I haz the power, 2016-10-10 19:37:14]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-10 20:09:19]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-10 20:09:20]

Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[dmazzoni, 2016-10-11 18:43:11]

The CQ bit was checked by dmazzoni@chromium.org

[dmazzoni, 2016-10-11 18:43:11]

The patchset sent to the CQ was uploaded after l-g-t-m from
ellyjones@chromium.org
Link to the patchset: https://codereview.chromium.org/2393123002/#ps60001
(title: "Made test more robust")

[commit-bot: I haz the power, 2016-10-11 18:43:33]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-11 20:03:46]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2016-10-11 20:06:43]

Description was changed from

==========
Implement caching asynchronous accessibility hit testing.

Native accessibility APIs all have some sort of "hit test"
function. Unfortunately on Mac, Windows, and Linux, they're all
synchronous APIs. This is problematic for Chrome because only
the render process can do an accurate hit test.

Previously we relied on an approximate hit test based on
accessible bounding boxes in the browser process. This was
okay for debugging, but not for users with low-vision who want
the accessible cursor to follow the mouse accurately.

To fix it, every time we get a hit test request we send an
asynchronous message to do an accurate hit test. While waiting,
we return an approximate hit test result instead. The next time
the mouse moves, if it's within the bounds of the object found
by the asynchronous hit test, we return that.

In practice it works well - as you mouse over an object, the
first pixel you cross will occasionally return the wrong object,
but one or two pixels later the correct object has been returned
by Blink and then it's correct.

Includes a test that confirms this behavior, that calling the
hit test first returns an approximate result and then later
returns the correct result if you call it repeatedly.

BUG=652996
==========

to

==========
Implement caching asynchronous accessibility hit testing.

Native accessibility APIs all have some sort of "hit test"
function. Unfortunately on Mac, Windows, and Linux, they're all
synchronous APIs. This is problematic for Chrome because only
the render process can do an accurate hit test.

Previously we relied on an approximate hit test based on
accessible bounding boxes in the browser process. This was
okay for debugging, but not for users with low-vision who want
the accessible cursor to follow the mouse accurately.

To fix it, every time we get a hit test request we send an
asynchronous message to do an accurate hit test. While waiting,
we return an approximate hit test result instead. The next time
the mouse moves, if it's within the bounds of the object found
by the asynchronous hit test, we return that.

In practice it works well - as you mouse over an object, the
first pixel you cross will occasionally return the wrong object,
but one or two pixels later the correct object has been returned
by Blink and then it's correct.

Includes a test that confirms this behavior, that calling the
hit test first returns an approximate result and then later
returns the correct result if you call it repeatedly.

BUG=652996

Committed: https://crrev.com/e7ca9f46f8f281febb2762ce693b7f8d93e25f9e
Cr-Commit-Position: refs/heads/master@{#424521}
==========

[commit-bot: I haz the power, 2016-10-11 20:06:44]

Patchset 4 (id:??) landed as
https://crrev.com/e7ca9f46f8f281febb2762ce693b7f8d93e25f9e
Cr-Commit-Position: refs/heads/master@{#424521}