New issue
Advanced search Search tips

Issue 897702 link

Starred by 2 users

Issue metadata

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



Sign in to add a comment

Regression(r450370): document.execCommand("insertHTML") with nested <span> is really slow

Project Member Reported by r...@igalia.com, Oct 22

Issue description


The attached example went from ~20ms to ~125ms after r450370.
The example creates a <p> with 100 nested <span> elements,
and inserts its using document.execCommand("insertHTML");
If you add more spans like 200, then the difference is much bigger.

Some Microsoft Word documents generates this kind of HTML when copying the whole document (even if it's a small document just one page),
pasting them on contenteditable is really slow.

I did a bisect and the range was:
https://chromium.googlesource.com/chromium/src/+log/f63ac52a3a74c9856d6fead1b1fb26a4948b35fe..d892f9592860691ae9a782c12260c94ed6bd1a63

So I believe the culprit is:
https://chromium.googlesource.com/chromium/src/+/d892f9592860691ae9a782c12260c94ed6bd1a63

 
insert-html-regression.html
464 bytes View Download
BTW, if you remove the wrapping paragraph from the example the times go from ~20ms to ~30ms so the regression hass less impact.
Cc: -yosin@chromium.org
Components: -Blink>Editing Blink>Editing>Command
Status: Available (was: Untriaged)
It seems ReplaceSelectionCommand::RemoveRedundantStylesAndKeepStyleSpanInline() consumes 82% of execution time due for creating VisibleSelection and VisiblePosition.
cr897702-1.png
73.2 KB View Download
cr897702-2.png
83.3 KB View Download
Cc: jfernan...@igalia.com
I didn't investigate this deeper but removing the call to RemoveNodePreservingChildren()
in ReplaceSelectionCommand::RemoveRedundantStylesAndKeepStyleSpanInline()
gets much better results:
https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/editing/commands/replace_selection_command.cc?q=RemoveNodePreservingChildren&sq=package:chromium&dr=CSs&l=622

I know that we cannot simply remove this line,
but it seems clear that this line is adding a big overhead.

Sign in to add a comment