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

Issue 635313 link

Starred by 2 users
Status: WontFix
Owner: ----
Closed: Sep 2016
Cc:
█ rnimmagadda@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

Big delay between typing and displaying text in bigger text area

Reported by gerald.h...@gmail.com, Aug 7 2016 
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36

Steps to reproduce the problem:
1. Open Page for Edit https://en.wikipedia.org/w/index.php?title=London&action=edit
2. Change some text. 
3. While typing one thread of the CPU is used 100%

What is the expected behavior?
Fluent typing, no delay between typing and desplay text

What went wrong?
When I try to change some text in the wiki-article chrome gets extremly slow. (Like MS-Word 2.0 on a 80386 PC in early 1990ies)

The image shows the CPU for typing 50 Chars. The CPU was at 100% for about half a Minute, and this was the time for desplaying the text in the textarea.

I think there is also a not cleaned up memory, because the issue gets worse with time of editing in over (smaller) articles.

Editing such a text like "London" in wikipedia is a pain. please do not analyse the hole text in the textarea for every keystroke. The CPU time for a single char is about 333ms!

Did this work before? Yes Textarea in Chrome was much faster some versions before (Spring 2016)

Chrome version: 52.0.2743.116  Channel: stable
OS Version: 
Flash Version: Shockwave Flash 22.0 r0
Screenshot_20160807_111747.png
19.1 KB View Download

Comment 1 by rnimmagadda@chromium.org, Aug 8 2016

Cc: rnimmagadda@chromium.org
Labels: Needs-Feedback
Unable to repro this issue on Ubuntu Trusty (14.04) for Google Chrome Stable Version - 52.0.2743.116

Screen-recording is attached.

@gerald.holzinger.public: Could you please re-test the same on a clean profile [chrome://settings -> Add Person -> Do not Login] and let us know your observations.

Thank you.
635313.ogv
19.4 MB Download

Comment 2 by gerald.h...@gmail.com, Aug 9 2016 

@rnimmagadda@chromium.org: 
Thank you, it helped a lot. I think I found the cause:

With my normal user-account to wikipedia I have enabled "wikEd" in https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-gadgets

You can turn off this tool by clicking the button right at the top. But even if the gadget is turned off at the page, the issue is reproduceable.

when I turn off the gadget in preferences, there is no issue. 
here is the link to wikEd main-page: https://en.wikipedia.org/wiki/User:Cacycle/wikEd

Comment 3 by rnimmagadda@chromium.org, Aug 9 2016 

@gerald.holzinger.public: Can we go ahead and close this issue if you are not able to repro this issue without that "wikED' extension?

Thank you.

Comment 4 by gerald.h...@gmail.com, Aug 9 2016 

I don't know how to close a task here.

I tested this issue with firefox, and there is a huge differenz between FF and chrome, FF is much faster for this use case.

I found the source of the skript here https://en.wikipedia.org/wiki/User:Cacycle/wikEd.js

Comment 5 by rnimmagadda@chromium.org, Aug 9 2016 

@gerald.holzinger.public: Can we go ahead and close this issue?

Thank you.
Project Member

Comment 6 by sheriffbot@chromium.org, Aug 17 2016

Labels: -Needs-Feedback Needs-Review
Owner: rnimmagadda@chromium.org
Thank you for providing more feedback. Adding requester "rnimmagadda@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 7 by rnimmagadda@chromium.org, Sep 14 2016

Labels: -Needs-Review
Owner: ----
Status: WontFix (was: Unconfirmed)
Closing this issue as per the comment #4
►

Sign in to add a comment