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.
Inserting the same long content with innerHTML takes about half a second.
Does this still happen? Do you know if it's a regression by any chance?
Component: General → Editor
Product: Firefox → Core
(Given the bug is pretty new, I suspect the answer to the first question is yes. Sorry if that sounds silly! :)
(Note that I can't reproduce a crash or sluggish performance under a debug build...)
WFM firefox-29.0.1.ru.linux64 2014-06-12-03-03-49-mozilla-central-firefox-33.0a1.ru.linux-x86_64
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.
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?
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.
(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?
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.
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: 5 years ago
Keywords: qawanted, regressionwindow-wanted
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.