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

Issue 869469 link

Starred by 1 user
Status: Assigned
Owner:
sadrul@chromium.org
Cc:
█ krajshree@chromium.org
susan.boorgula@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

When a Chrome_RenderWidgetHostHWND is focused, the focus is not visible

Reported by matthew....@gmail.com, Jul 31 
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/17.17134

Steps to reproduce the problem:
1. Create an Electron app
2. Put a focusable element in the HTML document which is loaded
3. Launch the app
4. Use your mouse to focus on the element
5. Hit tab

What is the expected behavior?
Wherever the focus goes, the focus is visible

What went wrong?
The focus is not visible. From using/debugging NVDA and looking at various accessibility tools, it is apparent that the window (a Chrome_RenderWidgetHostHWND) itself is getting focused. There is no way for the developer to disable this focus, or make it visible.

Did this work before? N/A 

Chrome version: 64.0.3282.140  Channel: n/a
OS Version: 10.0
Flash Version: 

Related: https://github.com/electron/electron/issues/12919

Comment 1 by dtapu...@chromium.org, Jul 31

Components: Blink>HTML>Focus

Comment 2 by tkent@chromium.org, Aug 1

Components: -Blink>HTML>Focus UI>Accessibility

Comment 3 by swarnasree.mukkala@chromium.org, Aug 1

Labels: Needs-Milestone

Comment 4 by krajshree@chromium.org, Aug 30

Cc: krajshree@chromium.org
Labels: Triaged-ET Needs-Feedback
Reporter@ - Thanks for filing the issue...!!

Could you please provide a sample test file/url to test the issue from TE-end. This will help us in triaging the issue further.

Thanks...!!

Comment 5 by aleventhal@chromium.org, Sep 21

Components: -UI>Accessibility UI>Aura
Owner: sadrul@chromium.org
sadrul@, any idea what we should do with this one?

Comment 6 by matthew....@gmail.com, Sep 21 

Apologies,I missed the notification asking for a repro example. I'll get y'all one as soon as I have a moment. I
Project Member

Comment 7 by sheriffbot@chromium.org, Sep 21

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

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

Comment 8 by susan.boorgula@chromium.org, Oct 10

Labels: Needs-Feedback
matthew.rayermann@ A gentle ping..

Request you to provide an update on this issue, which will help in further triaging.

Thanks..

Comment 9 by matthew....@gmail.com, Oct 30 

susan.boorgula@chromium.org, you can find repro steps at this electron bug: https://github.com/electron/electron/issues/12919

It's the best way I can find to repro the issue. Let me know if this is something that needs to be fixed in Electron rather than Chromium.
Project Member

Comment 10 by sheriffbot@chromium.org, Oct 30

Cc: susan.boorgula@chromium.org
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

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

Comment 11 by benhenry@google.com, Jan 11

Status: Assigned (was: Unconfirmed)
This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.
►

Sign in to add a comment