execCommand('inserthtml') crashes for long content

RESOLVED WORKSFORME

Status

()

--
critical
RESOLVED WORKSFORME
4 years ago
4 years ago

People

(Reporter: cacyclewp, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
Created attachment 8429657 [details]
testcase inserthtml crash on obama.html

1. Use execCommand('inserthtml') to insert long html content into iframe in designmode or contenteditable div
2. This is either unbearably slow or crashes the browser with crazy memory usage

Please try the attached testcase.

Long content:
   - Wikipedia article on Barack Obama
   - Highlighted by wikEd
   - Attributes removed from all highlighting tags
   - Invisible whitespace and comments removed
   - Code syntactically correct
   - No error messages in console

HTML content stats:
   - 780 <br> tags
   - 18,600 <span> tags
   - Maximal nesting: 7 levels
   - Text length: 250,000 chars
   - Total length: 500,000 chars

Browsers and system:
   - Chrome: 5 - 10 s, no additional memory required
   - Firefox 29: unresponsive, memory maxing out at 3.4 GB, crashes after a few minutes
   - Mozilla/5.0 (Windows NT 6.3; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0
   - All add-ons disabled
   - System: 8 GB RAM, Core i7-4600U @ 2.1 GHz, Windows 8.1

This is almost certainly a regression, but I have no idea when it happened.
(Reporter)

Comment 1

4 years ago
Inserting the same long content with innerHTML takes about half a second.

Comment 2

4 years ago
Does this still happen?  Do you know if it's a regression by any chance?
Component: General → Editor
Product: Firefox → Core

Comment 3

4 years ago
(Given the bug is pretty new, I suspect the answer to the first question is yes.  Sorry if that sounds silly! :)

Updated

4 years ago
Keywords: regressionwindow-wanted

Comment 4

4 years ago
(Note that I can't reproduce a crash or sluggish performance under a debug build...)

Comment 5

4 years ago
WFM
firefox-29.0.1.ru.linux64
2014-06-12-03-03-49-mozilla-central-firefox-33.0a1.ru.linux-x86_64
(Reporter)

Comment 6

4 years ago
Still having the problem using Nightly with a fresh profile. (33.0a1; Mozilla/5.0 (Windows NT 6.3; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0)

In the testcase you have to push the [Insert long content] button to trigger the bug.

Updated

4 years ago
Keywords: qawanted
I was unable to reproduce this bug using a Windows 8.1 64-bit machine with both Firefox 29.0 and several nightly builds from 2014-05-01 to 2014-07-09. I also tried replicating the issue on a Windows 7 64-bit machine, but still with no success. 

A spike in CPU usage does occur after pressing the [Insert long content] button, but other than a temporary (and intermittently) freeze that lasts for 1-2 seconds, there were no crashes.

Cacycle, are you still encountering this bug on your end?
Flags: needinfo?(cacyclewp)
(Reporter)

Comment 8

4 years ago
Yes, I still have the exact same problem with my normal profile and all add-ons disables as well as a with a fresh profile under the current Nightly. Temporarily disabling my antivirus (Avast) does not make a difference.
Flags: needinfo?(cacyclewp)
(In reply to Cacycle from comment #8)
> Yes, I still have the exact same problem with my normal profile and all
> add-ons disables as well as a with a fresh profile under the current
> Nightly. Temporarily disabling my antivirus (Avast) does not make a
> difference.

Thanks for the quick reply, Cacycle.

Have you also tried:
1. Replicating the bug in Safe Mode?
* see: https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode
2. Resetting Firefox?
* see: https://support.mozilla.org/en-US/kb/reset-firefox-easy-fix-most-problems
3. Replicating the bug on a different machine?
(Reporter)

Comment 10

4 years ago
I actually do not have this problem on a different laptop. I have tried safe mode and it does not help. I haven't tried resetting, but I would assume that this would be equivalent to using Nightly with a fresh profile.
(Reporter)

Comment 11

4 years ago
I see it also after:
- Resetting Firefox
- Fresh Firefox installation with fresh profile
- With antivirus disabled
- Booting into Windows safe mode with networking (together with the previous points)
- With all plugins disabled
Cacycle, thank you for taking the time to look further into this and respond to my information request. Unfortunately, I'm still unable to replicate the bug on any of my testing machines. Since Comment 4 and Comment 5 are also stating results that are similar with mine, this issue seems to be somehow isolated to your test environment.

If you manage to identify any other factors that prove otherwise, feel free to reopen this bug, but for now I'm marking this WFM.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Keywords: qawanted, regressionwindow-wanted
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.