Closed Bug 782359 Opened 9 years ago Closed 9 years ago
Browser hang when dynamically adding content editable div to a page with large JS literal
Attached is a test case that shows: - In a body script, dynamically add a content-editable DIV to the body - Afterwards, a long JS literal that is all on one line is set to a variable. The variable is not used. In this case, you can see that the browser hangs while processing the page. If the size of the JS literal is increased, the page hangs further. I can give a larger example if need be. The following makes the browser no longer hang: - Removing setting the contentEditable attribute of the element - Breaking up the JS literal across multiple lines Other browsers do not exhibit this behavior. This is the reduced test case of an issue that has impacted Google Docs.
Ehsan, can you look at this?
Cc'ing Ehsan and Aryeh to look at this as well as qawanted to find a regression window (assuming this is a regression).
Attachment #651482 - Attachment mime type: text/plain → text/html
Hmm, I cannot reproduce the hang. Which version of Firefox and what operating system are you seeing this on? Also, can you please verify that you're seeing the hang if you load the test case from the attachment on this bug (just so that we make sure we're looking at the exact same thing.) Thanks!
Also, if you have a larger test case which also reproduces this please attach that to the bug as well. Thanks!
Attachment #651515 - Attachment mime type: text/plain → text/html
Thanks for taking a look! Yes, the given tests case does freeze on my machine for ~5s. Attached is a similar test case, with more data in the JS array literal. This causes FF to freeze for a longer amount of time on my test setups. Fails on: FF 14.0.1 - Linux Ubuntu FF 14.0.1 - Mac OS X 10.6.8 Beachball on Mac, etc. All addons disabled.
(In reply to Steven Saviano from comment #5) > Created attachment 651515 [details] > larger JS data - longer freeze I don't see any hang with this.
(Nightly on Linux)
OK, I can reproduce the hang on Firefox 14 on Mac but not with Nightly, so it's probably something that has already been fixed.
Hmm, indeed. It even appears fixed in FF Beta 15.0 - Mac OS X 10.6.8 Apologies, I should have checked beta/nightly to begin with. Glad to see this is fixed.
Do you know when 15 will hit stable?
(In reply to Steven Saviano from comment #11) > Do you know when 15 will hit stable? Yes, August 28th. But I still want to know what's going on here, so I'm doing my local build to see if I can profile it.
(For future reference, this page lists our release schedule: https://wiki.mozilla.org/RapidRelease/Calendar)
OK, this is a dupe of the bug that I filed and fixed in Firefox 15: bug 755480. I am going to mark this as such. The fact that we attempt to spell check script elements is just plain stupid, and I have filed bug 782418 to get that fixed. Steven, is August 28th a good time for Google to see this fix in Firefox 15?
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 755480
Yes, August 28th will be great. Thanks for the prompt and thorough investigation! Much appreciated.
You need to log in before you can comment on or make changes to this bug.