Issue metadata
Sign in to add a comment
|
Accessibility APIs not enabling on Chrome on Windows
Reported by
afc.cha...@gmail.com,
Aug 30
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.72 Safari/537.36 Steps to reproduce the problem: 1. Try enabling chrome accessibility by calling the following Windows APIs hwnd -> window handle for "Chrome Legacy Window" 1. SendMessage(hwnd, WM_GETOBJECT, OBJID_CLIENT, 1); 2. AccessibleObjectFromWindow(hwnd, OBJID_CLIENT, IID_IAccessible, (void**)(&accObj)); 3. accObj->get_accValue(CHILDID_SELF, &return) get_accValue always returns S_FALSE; What is the expected behavior? get_accValue should pass with S_OK and give the URL in the return string What went wrong? I am suspecting it is because of this commit https://chromium.googlesource.com/chromium/src/+/df50ae4d2550f29f625ddac046e0ed65f398136e Though the above change suggests calling get_accName should enable it. But calling get_accName in the above sequence before get_accValue does not fix it. Also the above changelist suggests to work only with IAccessible2 interface Did this work before? Yes 68.0.3440.106 Does this work in other browsers? Yes Chrome version: 69.0.3497.72 Channel: beta OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: This is causing a major regression in our windows application and causes chrome windows to not be detected at all by using IAccessible API
,
Aug 30
,
Aug 31
,
Aug 31
As this issue seems to be related to Chrome Legacy Window which is related to Legacy Browser Support (LBS) and Windows APIs. Hence adding TE-NeedsTriageFromHYD label for further triaging. Thanks.!
,
Aug 31
Ran bisect with our application as a test case. Below is the output C:\Python27>python bisect-builds.py -g 561733 -b 587302 -a win64 --use-local-cache Downloading list of known revisions... Loaded revisions 389148-578269 from C:\Python27\.bisect-builds-cache.json Saved revisions 389148-587950 to C:\Python27\.bisect-builds-cache.json Downloading revision 574847... Received 133108300 of 133108300 bytes, 100.00% Bisecting range [561734 (good), 587299 (bad)], roughly 13 steps left. Trying revision 574847... Revision 574847 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 580779... Bisecting range [574847 (good), 587299 (bad)], roughly 12 steps left. Trying revision 580779... Revision 580779 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 583983... Bisecting range [580779 (good), 587299 (bad)], roughly 11 steps left. Trying revision 583983... Revision 583983 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 585495... Bisecting range [583983 (good), 587299 (bad)], roughly 10 steps left. Trying revision 585495... Revision 585495 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 586235... Bisecting range [585495 (good), 587299 (bad)], roughly 9 steps left. Trying revision 586235... Revision 586235 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 586776... Bisecting range [586235 (good), 587299 (bad)], roughly 8 steps left. Trying revision 586776... Revision 586776 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 586564... Bisecting range [586235 (good), 586776 (bad)], roughly 7 steps left. Trying revision 586564... Revision 586564 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 586355... Bisecting range [586235 (good), 586564 (bad)], roughly 6 steps left. Trying revision 586355... Revision 586355 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 586474... Bisecting range [586355 (good), 586564 (bad)], roughly 5 steps left. Trying revision 586474... Revision 586474 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 586411... Bisecting range [586355 (good), 586474 (bad)], roughly 4 steps left. Trying revision 586411... Revision 586411 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 586442... Bisecting range [586411 (good), 586474 (bad)], roughly 3 steps left. Trying revision 586442... Revision 586442 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 586450... Bisecting range [586442 (good), 586474 (bad)], roughly 2 steps left. Trying revision 586450... Revision 586450 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 586465... Bisecting range [586450 (good), 586474 (bad)], roughly 2 steps left. Trying revision 586465... Revision 586465 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g You are probably looking for a change made after 586465 (known good), but no later than 586474 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/bcb68779ca1d34cb992653cc880b95476c5b4055..4d18295073a6bf8f2f4d26e4e059767e091eaaf3 The diff contains the commit pointed out by the reporter.
,
Aug 31
Uploading a zip file which as small Visual C++ project + corresponding EXE. This is to facilitate with a test case for this issue. 1. Open Chrome Stable (68.0.3440.106) and navigate to chrome://accessibility/ 2. Run the EXE 3. Reload chrome://accessibility/ and it shows "Native accessibility API support" and "Web accessibility" enabled. The same does not work on Chrome Beta or Canary.
,
Aug 31
@dmazzoni and @chromium team, any update on this? Also, Is the above specified commit going to be a part of the Chrome Beta build that is going to become Chrome Stable on 4th September? I believe its a major regression and might break a lot of applications which use Chrome accessibility APIs.
,
Sep 1
,
Sep 2
Can we expect the above pointed / bisected Accessibility change commit to be a part of the Chrome Stable 69 (due on Sept 4th) ?
,
Sep 4
@Chromium team, any update on this?
,
Sep 4
Thanks for reaching out. I'd like to better understand Zynga's use case. Could you tell me more about what your application does and why it needs to access Chrome web content via IAccessible APIs? Do users understand that your application has access to all of the content of every web page that they visit, including passwords that they type? Our major motivation for the recent change was performance. Accessibility support has some memory and performance overhead. On most web sites, this overhead is modest, but there's a long tail of sites where performance is significantly degraded. In most cases, we found that users were not aware of the reason for this performance overhead. We've recently noticed a large increase in the number of Chrome Windows users with accessibility support enabled, so we made a deliberate decision to not enable accessibility support in cases where we might have before. We're not planning to roll back that change, but we're happy to work with you to better understand your use case and figure out a proper workaround. Long-term we hope to support a larger range of legitimate use cases with minimal performance overhead. If you'd prefer to communicate outside of this public bug tracker, feel free to email me at dmazzoni@google.com. However, I do plan to update this public bug with a summary of any high-level conclusions we reach.
,
Sep 5
Sure. I will be reaching out to your email for some additional context.
,
Sep 5
As bisect for this issue is provided in c#5. Hence removing needs-bisect label and adding label accordingly. Thanks! |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by afc.cha...@gmail.com
, Aug 30Also the aforementioned commit seems to execute the enabling method: BrowserAccessibilityStateImpl::GetInstance()->AddAccessibilityModeFlags( ui::AXMode::kNativeAPIs | ui::AXMode::kWebContents); } only if requested through IAccessible2 interface and not through IAccessible. Please let me know if i am getting this wrong.