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

Issue 777734 link

Starred by 2 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug
Team-Accessibility



Sign in to add a comment

Magnifier does not behave properly after tabbing between form fields

Reported by kamleshh...@gmail.com, Oct 24 2017

Issue description

for people like me with low vision, we use MAGNIFIER to use computer.
but while using magnifier in google chrome, the "TAB" function of keyboard is not visible in magnifier. Although the the cursor moves to next box or TAB, but the same is not visible in magnifier.
for example there are two boxes on any website for "username" and "password", while filling the username first, we us "TAB" to move to "password" box, although the cursor will move to "password" box but it will not reflect in magnifier. but it reflects while using internet explorer.

This is really a severe bug for people with low visibility and are using magnifier to use computer

I hope this bug qualify for "CHROME REWARD"





 
Components: UI>Accessibility
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Needs-Feedback Type-Bug
Summary: Magnifier does not behave properly after tabbing between form fields (was: key board tab function not working on google chrome browser for magifier visibility)
Thanks for the report. Can you explain what "will not reflect in magnifier" means specifically? Does the Magnifier when used in IE change so that it shows the newly-focused field? Or does something else happen?
HI

Let me explain you through video, PFA the video for your reference

the tabbing is properly working in CHROME, but the same is not reflecting
in magnifier screen while using tab from one field to another filed.

in short "follow mouse cursor" of magnifier is woring properly, but "follow
keyboard cursor" is not working in chrome.

The same is working in IE.

please check the video attached with this mail

Regards
Kamlesh
Project Member

Comment 3 by sheriffbot@chromium.org, Oct 25 2017

Cc: elawrence@chromium.org
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "elawrence@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: Needs-Milestone Needs-Feedback
kamleshhundia@,
For better understanding and triaging the bug, could you please attach video here for reference as mentioned in C#2 also on which OS & chrome version you observed the issue?
Thanks..!
attached video for your reference
Project Member

Comment 6 by sheriffbot@chromium.org, Oct 25 2017

Cc: jmukthavaram@chromium.org
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "jmukthavaram@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Hi

Any update on this issue ?

Will it be considered for google reward ?
If yes, how and when ?
Cc: divya.pa...@techmahindra.com
Labels: Needs-Feedback Triaged-ET
@kamleshhundia: Looks like you missed to attach video in C#2 and C#5. As per comment 4 could you please let us know which OS and version you are seeing this issue
Labels: -Needs-Feedback
I can confirm this bug with Chrome 61, 63, and 64.3249 on Windows 10.

Repro: 

1. Win+R type "magnify" and hit enter. Magnify starts.
2. Configure a 300% Zoom, click the Options button and select only "Follow the keyboard focus" (as in the attached screenshot).
3. Visit https://bayden.com/test/forms/password-focus.htm
4. Tab between the top input and the bottom inputs.

Observe: Zoom window does not update to show the newly focused input controls.

- Internet Explorer, Edge, Firefox all work correctly.
- Opera and Chrome only follow focus to the omnibox, not when activating edits in the content display area. Running with --no-sandbox does not help.
- Brave doesn't work at all (even in its omnibox).

These symptoms seem to be consistent with the idea that the problem is in how Chrome manages input for the invisible renderer processes. We probably need the browser process to send some sort of message to the system about the location of keyboard input when we're managing input for a renderer.
MagnifySettings.png
13.1 KB View Download
Labels: -Needs-Milestone M-64 OS-Windows

Comment 11 Deleted

Status: Untriaged (was: Unconfirmed)
This appears to be somewhat expected (see https://www.chromium.org/developers/design-documents/accessibility)

You can get Magnifier to pick up the focus changes properly in either of two ways:

1. Start Chrome with this flag: --force-renderer-accessibility
2. Or, visit chrome://accessibility in Chrome and check the top two boxes
I wouldn't say that's expected. Ideally Magnifier shouldn't require any special flags. Enabling accessibility manually is only intended for testing, not for end users. When the user is running a screen reader we automatically enable the support that's required.

Note that this change added support for Magnifier tracking the cursor - not sure what happened to the bug number on that one, but that was a large effort.

https://codereview.chromium.org/2852763002

Options:

1. We could detect that the user is using Magnifier and enable accessibility support automatically. That's what we do now for screen readers - we do it by looking for certain patterns of API calls. The problem with enabling it for any accessibility API calls is that these calls are used for many other things.

2. We used to have some code that created a "mini" accessibility tree that only contained the focused element, which was necessary to implement the Metro mode UI on Windows, but that code got removed when we abandoned that UI. I think something along those lines could work here, then Magnifier would just always work and we wouldn't even have to detect it.

Labels: Pri-3
It turns out that if you check Magnifier's "Have Magnifier follow the text insertion point" option, then Chrome 64 will follow the keyboard focus without changing either the chrome://accessibility settings or adding the command-line flags. So this is a pretty good workaround.
Google Chrome	64.0.3262.0 (Official Build) canary (64-bit) (cohort: Clang-64)
Windows 10 Enterprise Version 1607 Build 14393.1770
Windows Magnifier set to be as indicated by the user above: magnification set to 300%, Options > "set how much the view changes when zooming in or out" set to "100%", tracking set to "follow the keyboard focus" is checked and "follow the mouse pointer" it set to unchecked.   

Hello,

Just adding in a bit more context, I checked the following:

* Magnifier follows the text caret in Chrome correctly, even if chrome://accessibility shows no accessibility features are on
Steps taken:
# start Chrome canary
# navigate to chrome://accessibility and confirm that nothing is checked
# navigate to any webpage (I used https://en.wikipedia.org/wiki/Cat)
# use arrow keys to navigate, keep mouse in one location
- up and down arrow keys work as expected
- left and right arrow keys do nothing (they also do nothing if magnification is off)
- home, pg up, pg down, and end keys work as expected 

* Magnifier doesn't follow the focused item in Chrome (tab to links and buttons)
Steps taken:
# start Chrome canary
# navigate to chrome://accessibility and confirm that nothing is checked
# navigate to any webpage (I used https://en.wikipedia.org/wiki/Cat)
# Use tab multiple times to get focus moving across larger areas of text from link to link. 
# Note that focus is not followed. For example, I pressed tab through the links and noted that the focus highlight would not stay within the magnified view. That is, the focus rectangle could move outside of the magnified portion of the screen. 

* If you enable the top two checkboxes in chrome://accessibility, then Magnifier follows focus too
# start Chrome canary
# navigate to chrome://accessibility and confirm that the following boxes are checked: "Native accessibility API support" and "Web accessibility" 
# navigate to any webpage (I used https://en.wikipedia.org/wiki/Cat)
# Use tab multiple times to get focus moving across larger areas of text from link to link. 
# Note that magnifier focus follows keyboard focus as expected. 
Using the same Windows OS and magnification settings in the previous comment, I checked parity with Firefox 56.0.2 (64-bit):

# Open Firefox and navigate to https://en.wikipedia.org/wiki/Cat
# Caret browsing - use up, down, home, pg up, pg down, end keys and check focus 
- magnifier focus moves as expected 

# Tab browsing, use tab to move between multiple links on the page
- magnifier focus moves as expected 


 



Hi all

Could you please advise how to get the google reward for finding this bug
As many of you already confirmed this bug

Comment 18 Deleted

Re #17: Chrome's Security Rewards program is described here: https://www.google.com/about/appsecurity/chrome-rewards/index.html

As this issue does not represent a security vulnerability, it is not eligible for an award.


Hi

This issue will help improve google interfaces
If these kind of issues are not eligible for rewards then in future who
will waste time to mention to google for any related issues and who will
waste time to give suggestion in improving google overall experience in
browser and other google facility

Check and revert back

Regards
Kamlesh
Status: Available (was: Untriaged)
Hi Kamlesh,

Thanks so much for submitting this bug! I have triaged it and am marking it as available. 

This is not a security bug so it is not eligible for our security rewards program per the documentation: https://www.google.com/about/appsecurity/chrome-rewards/index.html

Thanks,

Laura 
Hi Laura

It means next time users should not bother themselves to help google to
improve its interfaces

And better to use other browsers from other providers

If it doesn’t eligible for security bug then it should be eligible for
other programs

Please advise

Regards
Kamlesh
Re #22: For issue reports unrelated to security, financial rewards are not provided. Non-financial rewards come in the form of a potential fix in the product, and personal satisfaction in helping to improve the browser for your own use and that of the community at large. Thank you for the report!
Labels: a11y-secondary
no changes have been done yet it seems
Project Member

Comment 26 by sheriffbot@chromium.org, Dec 14

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sign in to add a comment