Issue metadata
Sign in to add a comment
|
Typing into contentEditable can have a 2s delay
Reported by
s...@benchling.com,
Aug 17 2016
|
||||||||||||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Example URL: https://benchling.com/saif/f/pKCJaDmR-chrome-errors-public/etr-VLYYw3AA-typing-perf-issue-in-chrome/edit Steps to reproduce the problem: 1. Sign up for Benchling: https://benchling.com/signup 2. Visit https://benchling.com/saif/f/pKCJaDmR-chrome-errors-public/etr-uBFzCwNv-chrome-typing-perf-issue/edit 3. Clone the entry into your own personal account: http://i.h4k.im/cpxFB.png 4. Double-click to edit cell D3. 5. Type several characters. What is the expected behavior? Typing should not lag. What went wrong? Typing is delayed and shows up with a 2+ second lag. Does it occur on multiple sites: N/A Is it a problem with a plugin? N/A Did this work before? Yes Chrome 51 ? Does this work in other browsers? Yes Chrome version: 52.0.2743.116m Channel: stable OS Version: Windows NT 10.0 Flash Version: I tried this on other laptops running Windows 10 with a fresh install of Chrome 52, but I was unable to reproduce the issue. I watched a user perform the repro, and had them record the timeline profile (which is attached) and save chrome://gpu. I also had them try disabling hardware acceleration, but this did not have any impact. If you visit https://benchling.com/saif/f/pKCJaDmR-chrome-errors-public/etr-uBFzCwNv-chrome-typing-perf-issue/edit I outline some of the things I noticed about the timeline. I'm very confused by the key down under "Interactions > Input Events" stacking on top of each and taking a long time. All of the javascript handlers for these events are triggered afterwards and run fairly quickly. I would appreciate some tips in understanding what the timeline is showing / what other information I can collect.
,
Aug 17 2016
Here's a simpler repro: From http://jsfiddle.net/mq4h7f5L/3/ Type a few characters into the contentEditable On a Windows 8 i5 machine running, Chromium 52.0.2743.116 (64-bit), I'm getting large "other" chunks that cause the input events to be delayed.
,
Aug 17 2016
I've observed that lag is proportional to the number of nodes next to the contentEditable: I've recorded my observations here: https://benchling.com/saif/f/pKCJaDmR-chrome-errors-public/etr-MaiJMxgj-chrome-typing-perf-simple-repro/edit Also, running this on OSX 10.10.5, running Chrome Version 52.0.2743.116 (64-bit), it was a magnitude faster, and had no (gray) "other" chunks:
,
Aug 17 2016
As a follow-up, is there a way for me to debug what those gray "other" chunks correspond to? It's possible that the more elusive repro that I first outlined is experiencing a different, but similar symptom issue.
,
Aug 18 2016
,
Aug 18 2016
Perhaps a better repro: On Windows NT 6.3: 1. Visit http://i.h4k.im/00000/crbug-xyz/index.html (a stripped down version of the original repro, without requiring login or JS) 2. In cell D3, type "how are you doing" In Chromium 52.0.2743.116 on the same machine, I observed ~1fps when doing the above, the timeline JSON, screenshot of the timeline, and output of chrome://gpu are attached. On this same machine, in Chrome 51.0.2704.84, I observed ~20fps, which seems to indicate a regression.
,
Aug 22 2016
Whoops, didn't quite capture GPU correctly. I also recorded traces in Chrome 51 and Chromium 52 following the steps listed here: http://dev.chromium.org/developers/how-tos/trace-event-profiling-tool/recording-tracing-runs
,
Aug 23 2016
I don't see 2sec delay on my local desktop. In trace for M52 in #c7, - BaseArena::lazySweepPages called 3,023 times takes 76.1ms, - ThreadState::completeSweep called 11 times, takes 130.0ms in Renderer(pid 16596), MessageLoop::RunTask start 3,417.498ms keishi@, could take look?
,
Aug 23 2016
yosin@, keishi@, I've only be able to reproduce this on a couple of laptops. Let me know if there is anything else I should collect / measure!
,
Aug 23 2016
I can't reproduce the slowness too. Looking at the trace file from #c7, BlinkGC is using Marking(70ms)+LazySweep(70ms)+CompleteSweep(130ms)=270ms out of 2 seconds in TaskQueueManager::RunTask so only 14%. This means that BlinkGC itself is not the problem and indicates too many temporary objects being created inside Blink (ie not exposed to JS). yosin@ do you have any idea what the objects could be? saif@ The JS fiddle from comment 2 looks simple enough to work off of. Just to be sure, do you see slowness with that? Also if you have a chance could you record a trace with the categories blink, blink_gc, and disabled-by-default-blink_gc enabled. Inside the "Record a new trace..." dialog, select "Manually select settings" and check "blink" and "blink_gc" from the "Record Categories" column and "blink_gc" from the "Disabled by Default Categories" column. This will show us how much extra garbage is allocated helping us narrow down the culprit. Thanks.
,
Aug 23 2016
Also saif@, I see some accessibility related stuff in you trace. Do you have any accessibility features enabled?
,
Aug 23 2016
keishi@: I don't have access to the machine at the moment, but yes, I observed slowness in the jsfiddle. I'm unsure if there are any accessibility features that are on, but I'll be able to check / run the trace in about 6 hours. To double check, are the accessibility features you're seeing something I would find in chrome://settings or would they be in [Window's Ease of Access Center](https://support.microsoft.com/en-us/help/14205/windows-8-make-pc-easier-to-use) ?
,
Aug 23 2016
Sorry I'm unfamiliar with Windows specifics but Chrome's accessibility mode can be turned on by installing Chromevox or through OS settings (not through chrome://settings).
,
Aug 23 2016
keishi@, good call on the accessibility! I disabled "global accessibility mode" via chrome://accessibility and the performance regression disappeared! Hm, I tried the jsfiddle experiment again and now I see that Chrome 51 has about same performance as Chromium 52 (same slowness if I enable accessibility, same quickness if I disable it). However, the example on i.h4k.im is more substantial: Chrome 51 without accessibility: fast, ~30fps Chrome 51 with accessibility: slow, ~8fps Chromium 52 with accessibility: super slow, ~1fps Chromium 52 without accessibility: fast, ~30fps Is it expected for accessibility to cause such a dramatic slowdown? It does seem that there is a regression with accessibility? I can't seem to find what is triggered accessibility mode to turn on. It doesn't seem to stick when I change it from chrome:/accessibility (but at least there's a temporary fix) Attached are traces of running the jsfiddle in Chromium 52 with and without accessibility, as well as the native/internal accessibility trees for both Chromium 52 and Chrome 51 (the accessibility trees may be less interesting, since I observed similar slow speeds with accessibility mode for both Chrome 51 and Chromium 52)
,
Aug 23 2016
I am now able to reproduce this on OSX 10.10.5, running Chrome 52.0.2743.116 (64-bit). 1. Visit: chrome://accessibility 2. Turn on "Global accessibility mode" 3. Visit http://i.h4k.im/00000/crbug-xyz/index.html and type in cell D3, or visit http://jsfiddle.net/mq4h7f5L/3/ and type into the contentEditable. Would appreciate any insights in figuring out how to figure out why Chrome thinks it needs to run in accessibility mode. https://www.chromium.org/developers/design-documents/accessibility#TOC-How-Chrome-detects-the-presence-of-Assistive-Technology seems to indicate it happens auomatically, but I couldn't seem to find any accessibility features that are toggled on at the OS level. THe machine also doesn't have Chromevox installe.d
,
Aug 24 2016
Thanks I was able to repro the slowness with instructions in Comment 16. Judging from the traces in Comment 15, it looks like things like AccessibilityMsg_Events_ACK is taking an inordinate amount of time (~250ms). Memory allocation is low and BlinkGC seems to be operating normally. Turning on accessibility will always be slower. But being this slow to type seems like a bug. dmazzoni@ from AX team or yosin@ from editing team, is this a known issue? FYI on Mac, turning on VoiceOver from the System Preference app should turn on accessibility in Chrome.
,
Aug 24 2016
I'll take a look. Yes, there's a performance hit for accessibility but that's way beyond what we should see. I'll profile it and see what's happening. It'd also be useful to try to figure out why accessibility mode was enabled for this uesr. I've seen other reports of this anecdotally, but overall stats aren't showing any increase in the number of users with accessibility enabled. Besides assistive technology like screen readers (which is what accessibility was designed for), other things that use those APIs include: * Password managers like LastPass * Other automation software like clipboard managers, form fillers, auto-login, etc. * Drivers for touch screens on some laptops
,
Aug 24 2016
dmazzoni@, thanks for looking into this. I'll get back to you when I find out what caused the accessibility mode to be turned on. 1. Is there any way that a user can explicitly turn off accessibility mode? 2. Is there a way to detect from Javascript if a user has accessibility mode enabled? I'd like to warn users in our application that if they are on Chrome 52 with accessibility mode that they may experience degraded experience. Our site is unusable for some users because of this bug :( 3. Is there any hacky, temporary fix that I can apply to avoid the issue? I was guessing something like aria-hidden="true" might do the trick, but that doesn't seem to help. 4. Any rough time estimate of when this will be fixed?
,
Aug 25 2016
1. Is there any way that a user can explicitly turn off accessibility mode? From the command line, --disable-renderer-accessibility will make it never turn on. Otherwise, turn it off for a session with chrome://accessibility 2. Is there a way to detect from Javascript if a user has accessibility mode enabled? I'd like to warn users in our application that if they are on Chrome 52 with accessibility mode that they may experience degraded experience. Our site is unusable for some users because of this bug :( Not currently - it's controversial because some users with disabilities are concerned this is a privacy violation. 3. Is there any hacky, temporary fix that I can apply to avoid the issue? I was guessing something like aria-hidden="true" might do the trick, but that doesn't seem to help. I'd hate to fix it by making it inaccessible to users with disabilities. 4. Any rough time estimate of when this will be fixed? I'll try to update with the underlying cause within the next few days. Once we know that it may suggest a workaround, and I can give you a date when a fix can be released too. In the meantime, I'd love to know if you can narrow down what is triggering this for only a fraction of users. Things to try: * Can you reproduce on a different Windows machine? * Can you reproduce no a new fresh user account on the same (affected) machine? * Can you reproduce if you turn off anything nonessential like virus scanners and other third-party utilities that might be to blame?
,
Aug 30 2016
dmazzoni@: 2. Makes sense. 3. Agreed that it's aggressive to do this globally, so instead I'd like to give the option to our enterprise users that have complained to us about performance instead of telling them to use a different browser (or have them manually perform suggestion with 1) 4. Any updates? * Reproduced on several machines belonging to an enterprise customer * Reproduced on a new account, so it seems likely to be some standard installed software. * I haven't had a chance to try this yet, but will let you know.
,
Sep 1 2016
I've identified the change that caused the regression: https://chromium.googlesource.com/chromium/src/+/5bb13e6c74c867320875d2413b1e0666835e00c4 I'm working on a fix. There are two factors making it slow. One is calling a function way more times than needed from accessibility code, which is what I'm fixing now. The other thing that exacerbates the problem is how deep the focused node is - when constructing the event path for the focused element it's very long. It might be worth experimenting to see if eliminating a few levels of depth in the DOM makes a difference in performance. I will look into other workarounds now that I know the cause.
,
Sep 7 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/36ef7b3f562ce421927e6abc941e716db2eb9dc6 commit 36ef7b3f562ce421927e6abc941e716db2eb9dc6 Author: dmazzoni <dmazzoni@chromium.org> Date: Wed Sep 07 22:05:01 2016 Optimize BlinkAXTreeSource by adding freeze/thaw for things like root, focus. When profiling some sites that are slow to build an accessibility tree, a lot of time was spent retrieving the document, root accessibility object, or focused accessibility object. Introduce the concept of freezing BlinkAXTreeSource, which precomputes these once, and then allows them to be reused through the rest of a function scope. This is safe because the accessibility tree does not change during processing of an accessibility event. For one cs.chromium.org page, this sped up initial load by 50% (1000 ms to 650 ms) and single-node updates by 400% (90 ms to 23 ms). BUG= 631923 , 638474 Review-Url: https://codereview.chromium.org/2205083002 Cr-Commit-Position: refs/heads/master@{#417073} [modify] https://crrev.com/36ef7b3f562ce421927e6abc941e716db2eb9dc6/content/renderer/accessibility/blink_ax_tree_source.cc [modify] https://crrev.com/36ef7b3f562ce421927e6abc941e716db2eb9dc6/content/renderer/accessibility/blink_ax_tree_source.h [modify] https://crrev.com/36ef7b3f562ce421927e6abc941e716db2eb9dc6/content/renderer/accessibility/render_accessibility_impl.cc
,
Sep 9 2016
dmazzoni: thanks for the prompt fix, I'm unfamiliar with Chrome's release cycle... do you know about when this will hit stable? Is there an easy way for me to track this?
,
Sep 9 2016
Hi - you should be able to verify this in Chrome Canary now. Please let me know if you can confirm that this makes a significant difference. If you haven't tried it before, you can download Chrome Canary alongside the version of Chrome you already have installed and it won't interfere with any of its settings.
,
Sep 19 2016
Have you had a chance to verify?
,
Oct 27 2016
,
Jan 21
(2 days ago)
Possibly related to/dupe of https://bugs.chromium.org/p/chromium/issues/detail?id=582844 |
|||||||||||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||||||||||
Comment 1 by s...@benchling.com
, Aug 17 2016152 KB
152 KB View Download