1909171 - Copy-paste of text from local text editor to a Codepen demo appears to spend 10s around CSS parsing and memory usage grows to 3GB. Copy-paste from the browser is instant.

Status: RESOLVED WORKSFORME

(Core :: DOM: Editor, defect)

Description

[Mayank Bansal]

0. Download the attached sample text file to yoir local machine. Open the sample text file in your local editor.
1. Open attached testcase (original demo at https://codepen.io/dark_mefody/pen/PoLdPoY)
   1.1 Delete all the text in the demo area of the testcase
2. Copy-paste the sample text from the local editor into the demo area of the testcase
3. Now open the sample text in the browser and copy-paste its contents into the demo area of the testcase

AR:
Copy-paste from local file: profile with single style thread: https://share.firefox.dev/3zSoh5O (10s)
Copy-paste from firefox: https://share.firefox.dev/4fahuEL (instant)

Chrome is instant in both cases

Comment 1

[Mayank Bansal]

Attachment: standalone testcase.html

Comment 2

[Mayank Bansal]

Attachment: memory-report.json.gz . Look at PID=1928

Comment 3

[Mayank Bansal]

Attachment: Sample CSS text.css

Comment 4

[Emilio Cobos Álvarez [:emilio]]

Ok, simpler STR:

• Open attachment 9414067 [details]
• Open attachment 9414069 [details] on a separate tab.

On attachment 9414069 [details], select all (Ctrl+A) and copy (Ctrl+C).

On attachment 9414067 [details], paste without formatting (Ctrl+Shift+V).

The test-case is effectively a <style contenteditable spellcheck="false">. It seems the editor, instead of a single plain text node, will create a bunch of <br> elements, which means thousands of nodes. Every time a node is appended we need to re-parse the stylesheet.

Masayuki, it seems the editor could notify of all nodes at once? That'd make this fast. This one is a very extreme case but it's likely it matters for smaller subtrees too...

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #4)

The test-case is effectively a <style contenteditable spellcheck="false">. It seems the editor, instead of a single plain text node, will create a bunch of <br> elements, which means thousands of nodes.

Right.

Every time a node is appended we need to re-parse the stylesheet.

Masayuki, it seems the editor could notify of all nodes at once? That'd make this fast. This one is a very extreme case but it's likely it matters for smaller subtrees too...

mozAutoDocUpdate is what you think the editor should put before touching the DOM?

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Well, it might fix the issue in first edit, but not so for undo and redo unfortunately... It might be possible to make a new transaction for making a set of document update API calls, though.

Comment 7

[Emilio Cobos Álvarez [:emilio]]

Not necessarily just that (even tho that would help), but maybe even something along the lines of bug 1882417.

Comment 8

[Jan Jaeschke [:jjaschke]]

(Marking S3 for now because the test case seems rather obscure. Feel free to change)

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Thank you.

I think that including for saving foot print, there should be new transaction to insert multiple line text. Then, the transaction should do everything to touch the DOM with suppressing the notification. Then, undo/redo can also prevent the notifications too. And if we do that in same order, we can make the undo faster than now.

Comment 10

[Mayank Bansal]

Pasting normally: https://share.firefox.dev/44HEtUq
Pasting without formatting: https://share.firefox.dev/4lIwMUb

This is pretty much instantanous now. Calling it WFM.