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

Issue 730915 link

Starred by 1 user

Issue metadata

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



Sign in to add a comment

IAccessibleHypertext::hyperlink(0) fails on Gitter content iframe

Project Member Reported by ja...@nvaccess.org, Jun 8 2017

Issue description

Chrome Version: 61.0.3122.0 (Official Build) canary(64-bit)
OS: Windows 10 Version 1703 (OS Build 16199.1000) 64-bit

What steps will reproduce the problem?
(1) Start the NVDA screen reader and Chrome.
(2) Press control+shift+n to open a new Incognito window.
(3) Open this URL: https://gitter.im/nvaccess/nvda
(4) Wait a few seconds for the page to load.
(5) Press NVDA+f5 to refresh the content.
(6) Press control+end to go to the bottom of the document.

What is the expected result?
The bottom line should be "SIGN IN TO START TALKING".

What happens instead?
The bottom line is "Browser, Desktop and Mobile Apps."

If this works as expected the first time, try closing the window and repeating.

Additional info:
This is a little intermittent, though I can reproduce it every time with the above steps. Timing seems to play a significant part, unfortunately; if you simply refresh the page, sometimes it doesn't happen, as it loads faster. The NVDA+f5 bit isn't always necessary, but sometimes, we can get to the iframe initially and then it breaks later.

When this occurs, the accessible for the content iframe (tag: iframe; id: content-frame) returns E_FAIL when we call IAccessibleHypertext::hyperlink(0). nHyperlinks does return 1. You can get to the document using accNavigate, just not with hyperlink(0) (which is the normal way to access this because there is an embedded object character exposed by the text interface).

Impact: This makes Gitter unusable for Chrome + NVDA users most of the time.
 
Labels: triage-nektar
Labels: triage-lpalmaro
62.0.3200.0 (Official Build) canary (64-bit) (cohort: 64-Bit)
Windows 10 14393.1593

Hello Jamie, 

Thanks for the detailed repro steps and including the impact on users, you're a real help! I am able to reproduce this in Chrome 62. I will recommend it for triage. 

Thanks,

Laura 
I also wanted to mention that in Firefox 55.0.3 (64-bit), the functionality is different so they are not directly comparable. When I press ctrl + end in Firefox, it does not jump to the end, focus remains on the search bar. 
Status: Available (was: Untriaged)

Comment 6 by ja...@nvaccess.org, Sep 4 2017

> I also wanted to mention that in Firefox 55.0.3 (64-bit), the functionality is different so they are not directly comparable. When I press ctrl + end in Firefox, it does not jump to the end, focus remains on the search bar.

In Firefox, I see the expected results as I originally described; i.e. the bottom line is "SIGN IN TO START TALKING". I'd say there is a misconfiguration related to Firefox here. Note that accessibility isn't supported for Firefox multi-process, so if multi-process is enabled, you might be hitting this.

Comment 7 by nek...@chromium.org, Nov 14 2017

Cc: nek...@chromium.org
Owner: ----
Labels: win-a11y
Project Member

Comment 9 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