New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 812892 link

Starred by 2 users

Issue metadata

Status: Verified
Owner:
Closed: Mar 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows , iOS
Pri: 1
Type: Bug
Team-Accessibility



Sign in to add a comment

a11y: windows scaling affects caret position with AT, especially ZoomText

Project Member Reported by leberly@chromium.org, Feb 15 2018

Issue description

This happens with any version of Chrome at least 63 and above.
Google Chrome 66.0.3346.9 (Official Build) canary (64-bit) (cohort: 64-Bit)
Windows 10 Enterprise Version 1607
JAWS 2018.1801.81 ILM 
JAWS 18.0.4534
NVDA 2017.4 

Steps to repro:

# Change windows Display Settings > "Change the size of text, apps, and other items." to be 200%.  
# Launch Chrome
# Launch AT of your choice, this is most obvious with the ZoomText caret. It happens intermittently with the highlight on JAWS and rarely with the highlight add on with NVDA. 
# Note that the visual tracker for the caret is offset up and to the left. 
# Launch a native app such as Notepad, note that the caret is properly aligned with the visual tracker. 
# Go back to Windows Display Settings and return the size slider to 100%
# Note that the caret and the visual tracker are now lined up properly.  

We need to make decisions around if/how to support Windows scaling with AT. 
 
Cc: nek...@chromium.org leberly@chromium.org aleventhal@chromium.org
 Issue 811412  has been merged into this issue.
Labels: -Pri-2 OS-Chrome Pri-1
Owner: dmazz...@chromium.org
Update from dmazzoni@:

It's quite possible we have a bug when the Windows zoom level is set to something other than 100%. My observation has been that some AT is buggy as far as that goes, too. However in this particular case if the ZoomText focus ring is correct but the caret rect is not, only when the Windows zoom level is not 100%, then we probably have a bug with the caret rect. My guess is that probably we need to apply the device scale factor to the caret bounding box.The only thing I'm not clear on is the flickering. Does the flickering go away at 100% zoom? Is the flickering still an issue on Canary at 200% zoom?

Answer for Dominic:
The flickering only happens when the caret is offset. It flickers back and forth between the offset area and where it belongs. When the caret tracking is normal, there is no flickering. Happy to provide a video or repro in person, just let me know. 
Labels: -OS-Chrome
Status: Started (was: Available)
Project Member

Comment 4 by bugdroid1@chromium.org, Mar 9 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1c057f0d2dab299e19a702cbdebbd30102585700

commit 1c057f0d2dab299e19a702cbdebbd30102585700
Author: Dominic Mazzoni <dmazzoni@chromium.org>
Date: Fri Mar 09 19:13:16 2018

Convert from DIP to screen pixels for caret bounds

When the caret bounds are updated in RenderWidgetHostViewAura,
we need to convert from DIP to screen pixels, just like in
HWNDMessageHandler.

TBR=kenrb@chromium.org

Bug:  812892 
Change-Id: I0797c5b2ed85349b85d90ac3fe5b2e4f21775fe0
Reviewed-on: https://chromium-review.googlesource.com/956540
Commit-Queue: Dominic Mazzoni <dmazzoni@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Nektarios Paisios <nektar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#542187}
[modify] https://crrev.com/1c057f0d2dab299e19a702cbdebbd30102585700/content/browser/renderer_host/render_widget_host_view_aura.cc

Status: Fixed (was: Started)
Project Member

Comment 6 by bugdroid1@chromium.org, Mar 9 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e11d27a95740506d96c8779c01a40cf887a4813e

commit e11d27a95740506d96c8779c01a40cf887a4813e
Author: Dominic Mazzoni <dmazzoni@chromium.org>
Date: Fri Mar 09 19:51:14 2018

View accessibility bounds should be in pixels, not DIPs

The bounding box highlighted by assistive technology
like ZoomText is wrong if the display resolution is not
set to 100%.

BUG= 812892 ,820298

Change-Id: Id488583666c5e01e7aaed5ade7a5a3faeff900cd
Reviewed-on: https://chromium-review.googlesource.com/955545
Commit-Queue: Dominic Mazzoni <dmazzoni@chromium.org>
Reviewed-by: Nektarios Paisios <nektar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#542202}
[modify] https://crrev.com/e11d27a95740506d96c8779c01a40cf887a4813e/ui/views/accessibility/native_view_accessibility_base.cc
[modify] https://crrev.com/e11d27a95740506d96c8779c01a40cf887a4813e/ui/views/accessibility/native_view_accessibility_base.h
[modify] https://crrev.com/e11d27a95740506d96c8779c01a40cf887a4813e/ui/views/accessibility/native_view_accessibility_win.cc
[modify] https://crrev.com/e11d27a95740506d96c8779c01a40cf887a4813e/ui/views/accessibility/native_view_accessibility_win.h

Labels: a11y-testers
Status: Verified (was: Fixed)
Google Chrome	67.0.3369.0 (Official Build) canary (64-bit) (cohort: Clang-64)
Windows 10 Enterprise Version 1607
ZoomText 2018.1802.47.400 Public Release 

Windows scaling set to 175%
Screen resolution is set to 1920x1200 - Windows recommended
Works as expected in the latest version of Chrome Canary, caret lines up with caret rendered in docs.google.com.

Labels: -a11y-testers
Also tested with screen resolution set to 800x600 - not recommended by Windows. Works as expected.
Labels: ReleaseBlock-Stable Merge-Request-66 M-66
Labels: -Merge-Request-66 Merge-Approved-66 OS-iOS
Approving merge to M66. Branch:3359
Project Member

Comment 12 by bugdroid1@chromium.org, Mar 16 2018

Labels: -merge-approved-66 merge-merged-3359
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/06a6bbcf08074c759d5eeec6c56ef0c39cbef5b0

commit 06a6bbcf08074c759d5eeec6c56ef0c39cbef5b0
Author: Dominic Mazzoni <dmazzoni@chromium.org>
Date: Fri Mar 16 19:40:29 2018

Merge to M66: Convert from DIP to screen pixels for caret bounds

When the caret bounds are updated in RenderWidgetHostViewAura,
we need to convert from DIP to screen pixels, just like in
HWNDMessageHandler.

TBR=nektar@chromium.org

Bug:  812892 
Change-Id: I0797c5b2ed85349b85d90ac3fe5b2e4f21775fe0
Reviewed-on: https://chromium-review.googlesource.com/956540
Commit-Queue: Dominic Mazzoni <dmazzoni@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Nektarios Paisios <nektar@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#542187}(cherry picked from commit 1c057f0d2dab299e19a702cbdebbd30102585700)
Reviewed-on: https://chromium-review.googlesource.com/966691
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/branch-heads/3359@{#289}
Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276}
[modify] https://crrev.com/06a6bbcf08074c759d5eeec6c56ef0c39cbef5b0/content/browser/renderer_host/render_widget_host_view_aura.cc

Project Member

Comment 13 by bugdroid1@chromium.org, Mar 16 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b78982431d4784d509bbd0def618d075b57b1544

commit b78982431d4784d509bbd0def618d075b57b1544
Author: Dominic Mazzoni <dmazzoni@chromium.org>
Date: Fri Mar 16 19:40:43 2018

Merge to m66: View accessibility bounds should be in pixels, not DIPs

The bounding box highlighted by assistive technology
like ZoomText is wrong if the display resolution is not
set to 100%.

BUG= 812892 ,820298
TBR=nektar@chromium.org

Change-Id: Id488583666c5e01e7aaed5ade7a5a3faeff900cd
Reviewed-on: https://chromium-review.googlesource.com/955545
Commit-Queue: Dominic Mazzoni <dmazzoni@chromium.org>
Reviewed-by: Nektarios Paisios <nektar@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#542202}(cherry picked from commit e11d27a95740506d96c8779c01a40cf887a4813e)
Reviewed-on: https://chromium-review.googlesource.com/966692
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/branch-heads/3359@{#290}
Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276}
[modify] https://crrev.com/b78982431d4784d509bbd0def618d075b57b1544/ui/views/accessibility/native_view_accessibility_base.cc
[modify] https://crrev.com/b78982431d4784d509bbd0def618d075b57b1544/ui/views/accessibility/native_view_accessibility_base.h
[modify] https://crrev.com/b78982431d4784d509bbd0def618d075b57b1544/ui/views/accessibility/native_view_accessibility_win.cc
[modify] https://crrev.com/b78982431d4784d509bbd0def618d075b57b1544/ui/views/accessibility/native_view_accessibility_win.h

Labels: Needs-Feedback
Unable to test the issue with steps mentioned in comment#0 hence tried verifying with steps in duplicated  issue 812892  on windows 10 with scaling as 200(recommended is 300%) 8840 x 2160 resolution.

1. Installed JAWS and in omnibox pasted  data:text/html,
<div>hello</div>
<input value="hello">.
2. Observed green focus on hello. Placed the focus in edit field and moved cursor and green highlight is still seen. Same behavior is seen in both builds with fix and without fix. 

Attaching screencasts for reference.

@dmazzoni: Requesting you to help us in verifying fix in latest M66 66.0.3359.45.

Thanks!
812892_without fix.mp4
1.8 MB View Download
812892_ 66.0.3359.45.mp4
1.4 MB View Download

Sign in to add a comment