New issue
Advanced search Search tips

Issue 671593 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 3
Type: Bug



Sign in to add a comment

UpdateSelectionBounds() called by Element::focus() causes page slow

Reported by martbgd@gmail.com, Dec 6 2016

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.90 Safari/537.36

Steps to reproduce the problem:
<html>
<head>
</head>
<body>
<div id="el"></div>

<script type="text/javascript">
function loop() {
    requestAnimationFrame(loop);
}
loop();

var html = '';
for(var i=0;i<10000;i++) {
    html+='asdfasdfasdfasdfasdfasdfasdfasdfasdfasdf';
}

var el = document.getElementById('el');
el.innerHTML = html;

el.setAttribute('contenteditable', true);
el.focus(); //<======= without this line everything is ok, but with this line high cpu usage (100%) never stops
el.removeAttribute('contenteditable');
</script>

</body>
</html>

What is the expected behavior?

What went wrong?
High CPU usage never stops

Did this work before? N/A 

Chrome version: 54.0.2840.90  Channel: n/a
OS Version: Ubuntu 16.04
Flash Version: Shockwave Flash 23.0 r0

I submitted an html file that reproduces the bug. The most interesting thing is that without 'el.focus();' line everything works as it should. Tested on Ubuntu 16.04.
 
bug.html
424 bytes View Download
Components: -Blink Blink>Editing>Selection
I've attached a trace. UpdateSelectionBounds seems to be taking 62ms per frame. The real question is why is it doing anything since nothing has changed?
trace_trace.json.gz
3.6 MB Download

Comment 2 by ajha@chromium.org, Dec 6 2016

Labels: M-54
Tagging with respective milestone for further triaging.
Cc: xiaoche...@chromium.org
Status: Untriaged (was: Unconfirmed)
UpdateSelectionBounds is for IME-related stuff.

The line "el.focus()" sets a non-null selection in the page, resulting a calculation of the rendered rectangle of the selection (in WebWidget::selectionBounds), which is time-costly.

It seems that IME is the only client of WebWidget::selectionBounds. If that is the case, there's a simple solution:
1. WebWidget::selectionBounds should return null if the selection is not in an editable element. Note that a function with similar purpose, InputMethodController::textInputInfo, is already doing this.
2. WebWidget::selectionBounds should be renamed to prevent misusing.
Status: Available (was: Untriaged)
Untriaged/Unconfirmed mean the issue is not recognized by chromium eng.
Please tag Available this case.

Comment 5 by yosin@chromium.org, Mar 23 2017

Labels: Hotlist-GoodFirstBug Performance
Per-#c3, it seems it is easy to fix this.
Labels: -Performance Performance-Loading
Status: Untriaged (was: Available)

Comment 7 by yosin@chromium.org, Sep 22 2017

Status: Available (was: Untriaged)
Summary: UpdateSelectionBounds() called by Element::focus() causes page slow (was: High CPU usage never stops)

Comment 8 by yosin@chromium.org, Oct 4 2017

Labels: Pri-3
Is this currently being worked on? If not, I'd like to take a crack at it.
Thanks mnemethp@, please feel free to take this.
Nobody works this.
Hi, can I get started this issue?
sjh836@: Sure, feel free to explore!
Sorry I went rogue on this bug. School ended up being more heavy than I thought this semester. sjh836@ feel free to nab this from me! Let me know if you need help :)

Sign in to add a comment