commit | fa9756916c92bcd5a6c71e2c9168b8873ff7f75b | [log] [tgz] |
---|---|---|
author | Kevin Babbitt <kbabbitt@microsoft.com> | Wed Apr 01 15:31:31 2020 |
committer | Commit Bot <commit-bot@chromium.org> | Wed Apr 01 15:31:31 2020 |
tree | e7b9948e63155e59c69dae25b4d92befbedc1281 | |
parent | 531ee9621f796a320f9691557a2f60e6238dd99b [diff] |
a11y: Make handling of device scale factor consistent This patch fixes several issues that were causing problems with accessibility hit testing and bounding rectangles when device scale factor was something other than 1, for example on a high-DPI monitor. In making these changes I'm adopting Blink terminology for various coordinate spaces: http://www.chromium.org/developers/design-documents/blink-coordinate-spaces - Device scale factor: Blink will apply device scale factor either at the transition from screen coordinates to physical pixels, or at the transition from CSS pixels to document pixels, depending on whether use-zoom-for-dsf is enabled. By contrast, Views will always apply device scale factor at the transition from screen coordinates to physical pixels in order to present UI in device-independent pixels. For accessibility this means that at the node level, application of device scale factor must be handled at the delegate level. That in turn means that callers of AXPlatformNodeDelegate must pass and receive values in physical pixels. - Windows: There may be flags to control what Windows platform APIs report and expect, but it appears that in our configuration the answer is always "physical pixels" regardless of monitor DPI. Platform API implementations have been adjusted to reflect this fact. - Also on Windows, when retrieving view bounds from the render widget, we were incorrectly always applying device scale factor regardless of use-zoom-for-dsf feature state. Fixed the code to take feature state into account and added an explanatory comment. - I could not find any test coverage exercising various combinations of device-scale-factor and use-zoom-for-dsf cross-platform -- all of the existing tests run according to the host device's defaults. Added a test to exercise these combinations independent of device configuration. Bug: 1007488 Change-Id: If111a7ce3f60829bb9c69cc4d641b0d204409c4d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2117330 Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org> Reviewed-by: Ian Prest <iapres@microsoft.com> Reviewed-by: Scott Violet <sky@chromium.org> Commit-Queue: Kevin Babbitt <kbabbitt@microsoft.com> Cr-Commit-Position: refs/heads/master@{#755358}
Chromium is an open-source browser project that aims to build a safer, faster, and more stable way for all users to experience the web.
The project's web site is https://www.chromium.org.
Documentation in the source is rooted in docs/README.md.
Learn how to Get Around the Chromium Source Code Directory Structure .
For historical reasons, there are some small top level directories. Now the guidance is that new top level directories are for product (e.g. Chrome, Android WebView, Ash). Even if these products have multiple executables, the code should be in subdirectories of the product.