782359 - Browser hang when dynamically adding content editable div to a page with large JS literal

Status: RESOLVED DUPLICATE of bug 755480

(Firefox :: Untriaged, defect)

Description

[Steven Saviano]

Attachment: Test case that shows browser hang when opening HTML. Can add more content to JS object literal and browser would hang longer.

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.

Comment 1

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Ehsan, can you look at this?

Comment 2

[Lukas Blakk [:lsblakk] use ?needinfo]

Cc'ing Ehsan and Aryeh to look at this as well as qawanted to find a regression window (assuming this is a regression).

Comment 3

[(no longer active)]

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!

Comment 4

[(no longer active)]

Also, if you have a larger test case which also reproduces this please attach that to the bug as well.  Thanks!

Comment 5

[Steven Saviano]

Attachment: larger JS data - longer freeze

Comment 6

[Steven Saviano]

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.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

(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.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

(Nightly on Linux)

Comment 9

[(no longer active)]

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.

Comment 10

[Steven Saviano]

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.

Comment 11

[Steven Saviano]

Do you know when 15 will hit stable?

Comment 12

[(no longer active)]

(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.

Comment 13

[(no longer active)]

(For future reference, this page lists our release schedule: https://wiki.mozilla.org/RapidRelease/Calendar)

Comment 14

[(no longer active)]

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?

Comment 15

[Steven Saviano]

Yes, August 28th will be great.

Thanks for the prompt and thorough investigation! Much appreciated.