Issue metadata
Sign in to add a comment
|
Performance issue: TextArea very slow when accessibility API turned on
Reported by
george.p...@gmail.com,
Jul 30
|
||||||||||||||||||||||||
Issue descriptionChrome Version: Version 70.0.3508.0 (Developer Build) (64-bit) Operating System and Version: Windows 10 Enterprise, Version 1803, Build 17134.167 URLs (if applicable): https://jsbin.com/tosewosali Description of performance problem: HTML <textarea> elements are very slow when the accessibility APIs are turned on, e.g. when the user is running a screen reader. Scrolling has severe, visible lag even when there's little content in the <textarea> (~1000 lines), and the tab hangs entirely when there's more content (~10,000 lines). Steps to reproduce: 1. Turn on Chrome's accesibility support by going to chrome://accessibility/ and ticking all the checkboxes. (Alternatively, run a screen reader.) 2. Open a page with a <textarea> containing ~1000 lines of text, e.g. https://jsbin.com/tosewosali 3. Scroll; the response is slow and janky Comments: The same happens if the <textarea> is initially empty and the content is pasted in. See the attached .gif for an example. I have also attached a trace file from chrome://tracing/
,
Jul 30
,
Jul 30
Using "--force-renderer-accessibility" and the attached test.html, bisected to c101cb728aecdd2bb77d29ebe8deaee47261f65e "Accessibility should always serialize an entire block when something changes." Landed in 69.0.3497.0
,
Jul 30
,
Jul 30
,
Jul 31
Able to reproduce this issue on Windows 10, Mac OS 10.13.3 and Ubuntu 16.04 on the latest Canary 70.0.3507.0 and latest Dev 69.0.3497.12 as per comment #3. Bisect Information: =================== Good Build: 69.0.3496.0 Bad Build : 69.0.3497.0 As per comment #3, suspecting the below change: Reviewed-on: https://chromium-review.googlesource.com/1062661 dmazzoni@ Please check and confirm if this issue is related to your change, else help us in assigning to the right owner. Adding 'ReleaseBlock-Stable' as this is a recent regression. Please feel free to remove if it is not applicable. Thanks..
,
Aug 3
I want to see if https://chromium-review.googlesource.com/c/chromium/src/+/1152180 fixes this issue too.
,
Aug 7
M69 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. Thank you.
,
Aug 9
,
Aug 13
dmazzoni@ I can still reproduce this issue on the latest trunk build (Version 70.0.3522.0 - https://crrev.com/582628), so your other change doesn't seem to have fixed it.
,
Aug 13
M69 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. Thank you.
,
Aug 14
Working on a revert here: https://chromium-review.googlesource.com/c/chromium/src/+/1174851
,
Aug 14
Pls request a merge to M69 once revert listed at #12 is landed in canary and looks safe to merge to M69. Thank you.
,
Aug 15
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b53fffcc225fd0f37ab7f56ba9f075f319d5e439 commit b53fffcc225fd0f37ab7f56ba9f075f319d5e439 Author: Dominic Mazzoni <dmazzoni@chromium.org> Date: Wed Aug 15 06:49:41 2018 Roll back code that serialized at the CSS block level due to performance. crrev.com/c/1062661 made it so that any time an accessibility node changes, we re-serialize the entire CSS block it's contained in - while this fixed some correctness issues, it introduced a performance regression that's too significant to ignore. This change rolls back the fix for now until we can find a way to fix it that doesn't impact performance. TBR=dtseng@chromium.org Bug: 868830 , 865621, 843746 Change-Id: I900a4e6ba796608974e881f091b99b0d45c09536 Reviewed-on: https://chromium-review.googlesource.com/1174851 Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org> Commit-Queue: Dominic Mazzoni <dmazzoni@chromium.org> Cr-Commit-Position: refs/heads/master@{#583182} [modify] https://crrev.com/b53fffcc225fd0f37ab7f56ba9f075f319d5e439/content/browser/accessibility/line_layout_browsertest.cc [modify] https://crrev.com/b53fffcc225fd0f37ab7f56ba9f075f319d5e439/content/renderer/accessibility/render_accessibility_impl.cc [modify] https://crrev.com/b53fffcc225fd0f37ab7f56ba9f075f319d5e439/content/test/data/accessibility/event/aria-combo-box-next-expected-win.txt [modify] https://crrev.com/b53fffcc225fd0f37ab7f56ba9f075f319d5e439/content/test/data/accessibility/event/listbox-next-expected-win.txt [modify] https://crrev.com/b53fffcc225fd0f37ab7f56ba9f075f319d5e439/content/test/data/accessibility/event/menulist-collapse-expected-mac.txt [modify] https://crrev.com/b53fffcc225fd0f37ab7f56ba9f075f319d5e439/content/test/data/accessibility/event/menulist-collapse-expected-win.txt [modify] https://crrev.com/b53fffcc225fd0f37ab7f56ba9f075f319d5e439/content/test/data/accessibility/event/menulist-focus-expected-mac.txt [modify] https://crrev.com/b53fffcc225fd0f37ab7f56ba9f075f319d5e439/content/test/data/accessibility/event/menulist-focus-expected-win.txt
,
Aug 15
Can confirm that https://crrev.com/583195 does not exhibit the issue. Thank you.
,
Aug 15
As noted in #15, I can confirm that the regression introduced at c101cb728aecdd2bb77d29ebe8deaee47261f65e has been fixed. However, the underlying performance issue which is blocking accessibility improvements in VSCode still exists. (I was confused and thought the regression was the issue we were facing in VSCode, but it can't be, since it never made it to Electron.) Here are steps to reproduce the underlying issue: 1. Turn on Chrome's accessbility support by going to chrome://accessibility and ticking 'Native accessibility API support' and 'Web accessibility' 2. On the same page, tick 'Text metrics'. (This is turned on by default when a screen reader, e.g. NVDA, is used.) 3. Open a page with a large <textarea> (10,000 lines) 4. The page is instantly unreponsive & hangs. No input events are executed -- all time out (see trace). This triggers specifically when 'text metrics' is on. It seems there's some sort of infinite loop. See the attached GIF and trace from chrome://tracing. (I suppose it might be OK to remove the Release Block now, since this underlying issue has existed for at least 2 years.)
,
Aug 17
Hi George - I filed a new bug - http://crbug.com/875344 - for the 10k text area. I'll keep this bug for the regression release blocker. Thanks.
,
Aug 17
Requesting merge to M69, since we've verified that it fixes the regrsesion.
,
Aug 17
This bug requires manual review: M69 has already been promoted to the beta branch, so this requires manual review Please contact the milestone owner if you have questions. Owners: amineer@(Android), kariahda@(iOS), cindyb@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 17
Approving merge to M69 branch 3497 based on comment #18. Please merge. Thank you.
,
Aug 17
,
Aug 17
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/5c376201983d79d88a1650b108a83888853404d3 commit 5c376201983d79d88a1650b108a83888853404d3 Author: Dominic Mazzoni <dmazzoni@chromium.org> Date: Fri Aug 17 18:10:49 2018 Merge to M69: Roll back code that serialized at the CSS block level due to performance. crrev.com/c/1062661 made it so that any time an accessibility node changes, we re-serialize the entire CSS block it's contained in - while this fixed some correctness issues, it introduced a performance regression that's too significant to ignore. This change rolls back the fix for now until we can find a way to fix it that doesn't impact performance. TBR=dtseng@chromium.org Bug: 868830 , 865621, 843746 Change-Id: I900a4e6ba796608974e881f091b99b0d45c09536 Reviewed-on: https://chromium-review.googlesource.com/1174851 Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org> Commit-Queue: Dominic Mazzoni <dmazzoni@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#583182}(cherry picked from commit b53fffcc225fd0f37ab7f56ba9f075f319d5e439) Reviewed-on: https://chromium-review.googlesource.com/1180141 Cr-Commit-Position: refs/branch-heads/3497@{#691} Cr-Branched-From: 271eaf50594eb818c9295dc78d364aea18c82ea8-refs/heads/master@{#576753} [modify] https://crrev.com/5c376201983d79d88a1650b108a83888853404d3/content/browser/accessibility/line_layout_browsertest.cc [modify] https://crrev.com/5c376201983d79d88a1650b108a83888853404d3/content/renderer/accessibility/render_accessibility_impl.cc [modify] https://crrev.com/5c376201983d79d88a1650b108a83888853404d3/content/test/data/accessibility/event/aria-combo-box-next-expected-win.txt [modify] https://crrev.com/5c376201983d79d88a1650b108a83888853404d3/content/test/data/accessibility/event/listbox-next-expected-win.txt [modify] https://crrev.com/5c376201983d79d88a1650b108a83888853404d3/content/test/data/accessibility/event/menulist-collapse-expected-mac.txt [modify] https://crrev.com/5c376201983d79d88a1650b108a83888853404d3/content/test/data/accessibility/event/menulist-collapse-expected-win.txt [modify] https://crrev.com/5c376201983d79d88a1650b108a83888853404d3/content/test/data/accessibility/event/menulist-focus-expected-mac.txt [modify] https://crrev.com/5c376201983d79d88a1650b108a83888853404d3/content/test/data/accessibility/event/menulist-focus-expected-win.txt |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by george.p...@gmail.com
, Jul 30