"Paste without formatting" immediately after "Paste" causes the editor testcase to take infinite time
Categories
(Core :: DOM: Editor, defect)
Tracking
()
People
(Reporter: mayankleoboy1, Unassigned)
References
Details
Attachments
(3 files)
This is a sort of part2 of bug 1892514
- Open the attached testcase
- Open the attched sample text.
- Select all and copy (Ctrl+A, Ctrl+C)
Good scenario:
4. On the testcase Right Click -> Paste without Formatting
AR: Text is pasted in 2 seconds which is good
5. Now delete the whole text. Then Right Click -> Paste
AR: Text is pasted very fast which is good.
Bad scenario
4. On the testcase Right Click -> Paste
once the text is pasted, delete it all.
5. Go to the testcase and Right Click -> Paste without Formatting
AR: The browser will take infinite amount of time
Nightly : https://share.firefox.dev/4diITD0 / https://share.firefox.dev/4fJ3fHc (130s+)
To summarize, you can keep on doing EITHER "paste without formatting" OR "Paste" in a loop. But as soon as you do a "Paste" and immediately do a "Paste without formatting", the testcase blows up.
|
Reporter | |
Comment 1•1 year ago
|
||
|
|
Reporter | |
Updated•1 year ago
|
|
|
Reporter | |
Comment 2•1 year ago
|
||
FWIW, this bug does not repro on simple testcases like : data:text/html, <html style contenteditable spellcheck="false">
|
|
Reporter | |
Comment 3•1 year ago
•
|
||
Profile with this smaller sample : https://share.firefox.dev/3AluPdg
- The tiny blip at the 2.5s mark is the first action i take which is to "Paste" the text. (https://share.firefox.dev/4dLKcdI)
- The small area at 3s mark is when i select all the text (https://share.firefox.dev/4cqgeuE)
- Tiny blip here is when I delete the elected text. (https://share.firefox.dev/3WOyBDt)
-
- Why does it have so many "NotifySelectionListenersAfterRangeSet" runnables and not when i paste the text in #1 ?
- The large area starting from 5.2 is when I "Paste without formatting" as the second action.
Looks like both nsINode::ComputeIndexOf(nsINode const*) const and nsRange::DoSetRange<nsINode *,nsIContent *,nsINode *,nsIContent *>(mozilla::Range… are problematic.
jjaschke, can you take a look, please?
|
||
Comment 5•1 year ago
|
||
I think the issue here is that our editor fires mutation events for each inserted node during paste instead of doing so once at the end.
Masayuki, we've coincidentally discussed this in the course of Bug 1503581. Can we apply batching here?
I want to stop dispatching the legacy DOM mutation events even partially while our editor touches the DOM because the other browsers already stopped dispatching in the cases. However, partially doing it may make some legacy editor app uses confused since legacy app would be broken only in the pasting operations.
Smaug: Do you think it's okay to stop dispatching the legacy DOM mutation events only in specific edit command handler in our editor for the performance?
(IIRC, we need to make some event dispatchers use AsyncEventDispatcher if we block to run script. E.g., error event dispatchers of some elements.)
|
||
Comment 8•1 year ago
|
||
I'd rather try to stop dispatching mutation events at all, and not add any special cases https://github.com/whatwg/html/pull/10573
|
|
||
Comment 10•1 year ago
•
|
||
Chrome has disabled mutation events by default now. So we should also try to investigate that option on Nightly asap.
(Mutation Events have been deprecated in Firefox since 2012.)
|
|
Reporter | |
Comment 11•1 year ago
•
|
||
Retesting with enabling/disabling mutation events (bug 1914513)
dom.mutation_events.enabled= False : https://share.firefox.dev/3zc97bp
dom.mutation_events.enabled= True : https://share.firefox.dev/4cRHNwU
|
|
Reporter | |
Comment 12•1 year ago
|
||
Is there a plan or timeline to disable mutation events in Firefox?
(In reply to Mayank Bansal from comment #12)
Is there a plan or timeline to disable mutation events in Firefox?
|
|
||
Comment 14•1 year ago
•
|
||
We know that web sites use still mutation events, so we can't disable them now. But disabling is part of interop-25, so hopefully it will happen later this year (since finally all the browsers are trying to disable them, not only Firefox).
|
|
Reporter | |
Comment 15•11 months ago
|
||
The testcase with the original STR is basically good enough now.
Profile: https://share.firefox.dev/46suGCX
I will close this as WFM, but please reopen if you see anything worth improving more.
|
|
Reporter | |
Comment 16•11 months ago
|
||
There is this profile though, which seems different (to me): https://share.firefox.dev/4lLo4V5
Will file a new bug for this.
Description
•