Issue metadata
Sign in to add a comment
|
Chrome Takes Abnormally Time To Load And Is Unresponsive When HTML Contains Textarea With Large Content
Reported by
garystim...@gmail.com,
Jul 4 2016
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36 Example URL: https://jsfiddle.net/GazzaS/y529fn4m/ Steps to reproduce the problem: 1. In your HTML Source add a text area with very large content (see my example URL) 2. When you open the HTML page in Chrome it takes abnormal time to load and render the text area 3. Text area also becomes unresponsive to resizing in UI What is the expected behavior? If you try the example in IE11 or Chrome 49 it works perfectly with HTML rendering very quickly. What went wrong? The loading of the page is taking way too long for only 180kb of character data inside the text area. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? Yes Only could test back to Chrome 49 which works Does this work in other browsers? Yes Chrome version: 51.0.2704.106 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 22.0 r0 We found this when using TinyMCE with large Base64 embedded images. I have reported it to the TinyMCE team. This effects us as we currently use Textarea to display the html source of our embedded HTML content.
,
Jul 6 2016
I confirmed the massive slowness with Google Chrome 51 stable, but it's not so slow with Google Chrome 52 beta and 54 canary. garystimson@, can you check with Chrome 52 or later?
,
Jul 7 2016
M53 is still slow. Resizing TEXTAREA by dragging right bottom corner almost don't work. I attached trace on M53 by - Reloading https://jsfiddle.net/GazzaS/y529fn4m/ - Attempt to resize TEXTAREA by dragging right-bottom corner It seems FrameView::performLayout took time. The TEXTAREA contains BASE64 encoded JPEG which is too long.
,
Jul 7 2016
Hi, Yes we found in TinyMCE as we were choosing to embed the images in the content which was storing as Base64 in a text area. However investigation showed it was the text area causing the issues when it reaches a large size content. Like you said it becomes completely unusable with the resize or selecting text. This speed issue does not exist in IE 9, 10 or 11, Firefox, Safari or Chrome 49. I will download Chrome 52 and retest. Thanks, Gary
,
Jul 7 2016
Hi, Just tested 52.0.2743.60 beta-m (64-bit) and it is much quicker on the load and the rendering of the text area seems to be resolved. However resizing the text area and selecting text, although better is still slower than it should be. Thanks, Gary
,
Jul 8 2016
Repro without TEXTAREA: https://jsfiddle.net/y529fn4m/1/
,
Jul 8 2016
TE team, can you bisect using the repro from comment 6?
,
Jul 8 2016
Able to reproduce the issue on windows 7, Linux Ubuntu 14.04 and Mac 10.11.5 using chrome version 51.0.2704.106 and canary 54.0.2790.0. This is regression issue broken in M49.Please find the bisect information as below Narrow Bisect =============== Good - 49.0.2573.0 -- (build revision 361233) Bad - 49.0.2574.0 -- (build revision 361527) CHANGELOG URL: =================== https://chromium.googlesource.com/chromium/src/+log/20f3b2d0ee459ed4d743ce9cd8c95417d74f6d04..fa7fc32c5940dfd3d734ed3231b1295da4c3303e Possible suspect from the above change log https://chromium.googlesource.com/chromium/src/+/fa7fc32c5940dfd3d734ed3231b1295da4c3303e eae@ could you please look into this issue if it is related to your change,else please route this to an appropriate owner for this issue. Thanks,
,
Nov 1 2016
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by dgro...@chromium.org
, Jul 6 2016Labels: -Type-Bug Type-Bug-Regression