Chrome's web accessibility support causes massive performance issues
Reported by
e...@figma.com,
Aug 22
|
||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36 Steps to reproduce the problem: I work on Figma, a browser-based interface design tool. We were recently made aware of a severe Windows-specific performance issue. Here's the repro: 1. Sign in to Figma (signing up is free) 2. Create a new document 3. Draw a rectangle 4. Drag a selection box on and off the rectangle repeatedly What is the expected behavior? The performance of the application should be around at least 30fps at all times. What went wrong? After a few seconds of doing this, the pause that happens after the UI updates due to selection/deselection of the rectangle can reach up to over 1000ms. Users have reported that for longer sessions and larger documents the pauses can be over 4000ms (I have chrome://tracing recordings from them to prove it). Attached is a Developer Tools profile and a chrome://tracing recording of it happening for me. The issue completely disappears if you uncheck "Web accessibility" on chrome://accessibility. Another thing to point out is chrome://tracing shows all of the time being spent in "RenderAccessibilityImpl::SendPendingAccessibilityEvents". Did this work before? N/A Does this work in other browsers? Yes Chrome version: 68.0.3440.106 Channel: stable OS Version: Windows 10 Flash Version:
,
Aug 22
,
Aug 22
I can confirm that the issue is still present on Version 70.0.3529.3 (Official Build) canary (64-bit), so it's not fixed. I can also confirm that the issue disappears immediately when web accessibility support is disabled.
,
Aug 22
,
Aug 22
Is there a way to work around this by completely disabling accessibility features on our page? I tried using <body aria-hidden="true"> and that greatly reduces the problem by around 10x (300-500ms instead of 3000-5000ms) but doesn't eliminate it. Another option we're considering is trying to detect when this is happening and then instructing our users to navigate to chrome://accessibility and uncheck "Web accessibility" themselves.
,
Aug 22
,
Aug 22
We're about to ship <body aria-hidden="true"> to our users later today, so reproducing this issue will now involve the additional step of first removing the "aria-hidden" attribute from the body tag. The repro steps are now: 1. Sign in to Figma (signing up is free) 2. Create a new document 3. Remove the "aria-hidden" attribute from the body tag if it's present 4. Draw a rectangle 5. Drag a selection box on and off the rectangle repeatedly Also: if you're wondering what step 5 looks like, the "developer-tools-profile.json" file attached in the issue report above also contains screenshots of what the interaction looks like. These can be viewed by loading that file in the Performance tab of Chrome Developer Tools.
,
Aug 23
evan@ Thanks for the issue. Tested this issue on Windows 10 on the reported version 68.0.3440.106 and the latest Canary 70.0.3530.0 and unable to reproduce the issue by following the below steps. 1. Launched Chrome and signed into https://www.figma.com. 2. Created a new document and removed "aria-hidden" attribute in Devtools -> Elements. 3. Enabled the FPS meter in Devtools -> Console -> Rendering. 4. Drew a rectangle and dragged the selection box repeatedly and could observe that the performance of the application is ~30-60 fps and could not observe any performance issues. Attached is the screen cast for reference. Note: "Web accessibility" is unchecked in chrome://accessibility while following the above steps. Request you to check and confirm if anything is missed from our end in triaging the issue. Also request you to retry the issue on a new chrome profile without any flags/ extensions and update the thread with the observations. Thanks..
,
Aug 23
This is a bug with Chrome's web accessibility support, so it only happens when "Web accessibility" is checked in chrome://accessibility. It will not reproduce if "Web accessibility" is unchecked. I'm actually able to reproduce this on both macOS and on Windows. The reason why it originally appeared to be a Windows-only issue is because Chrome appears to only enable "Web accessibility" by default on Windows, not on macOS. Attached is a video of the bug happening. I recorded it on macOS instead of Windows because I don't need a 3rd-party app to do screen recording on macOS. But it's the exact same issue as on Windows.
,
Aug 23
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
,
Aug 23
Evan, I'll take a look. There's definitely performance overhead to accessibility support but it shouldn't be that massive. Hopefully there's a specific bug that's triggered by your site that we can fix. Note that Chrome does not enable web accessibility on any platform by default. It's only triggered when third-party software accesses Chrome via accessibility APIs. Is it possible you have a touch screen? We've seen reports of Windows users with touch screens experiencing issues related to accessibility. This may be something new, like suddenly in the last few weeks some driver started using accessibility APIs that it wasn't using before. If it's not related to a touch screen, look carefully at any other software you have running, see if the problem goes away when you turn off virus scanners, password fillers, etc.
,
Aug 23
Ah, I see. When we reproduced this ourselves it was on a Microsoft Surface tablet with a touch screen, so that's probably what happened. We did have a user say that Windows update KB4340917 was what triggered the issue for them in case it's useful. That was released on July 24th, 2018 according to https://support.microsoft.com/en-us/help/4340917/windows-10-update-kb4340917.
,
Aug 23
Thanks, that's helpful.
,
Aug 24
Able to reproduce the issue on Windows 10, Mac OS 10.13.3 and Ubuntu 17.10 on reported version 68.0.3440.106 and on latest canary 70.0.3530.0 as per comment #9. This issue is observed from M-60 chrome builds. Attached is the screen cast for reference. Hence removing 'Needs-Bisect' label and adding the appropriate labels for further update on this issue. Thanks!
,
Aug 27
,
Aug 28
We've mitigated this by solving the problem that was causing accessibility to be enabled for millions of users who didn't otherwise need it. Long-term we'll definitely still be looking into fixing the performance issues.
,
Oct 18
|
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by woxxom@gmail.com
, Aug 22