519076 - inserthtml for iframe in designmode is unbearably slow for Firefox 3.5 but not older versions

Status: VERIFIED WORKSFORME

(Core :: DOM: Editor, defect)

Description

[Cacycle]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)

Inserting very long html strings into an iframe in designmode using execCommand('inserthtml') takes unbearably long in Firefox 3.5. 

The attached testcase inserts a 1.4 MB text with dense html code. What takes less than one second in SeaMonkey 1.1.18 (Gecko/20090825) takes more than 10 s in Firefox 3.5!

This bug critically affects syntax highlighting in rich text editors like wikEd on Wikipedia (http://en.wikipedia.org/wiki/User:Cacycle/wikEd).  The testcase is a real example of the highlighted content from the Wikipedia article on Barack Obama. No editing user will accept an additional 10 s browser freeze after the already somewhat time consuming highlighting process (1.6 s for this example).



Reproducible: Always

Comment 1

[Cacycle]

Attachment: Testcase (inserthtml of 1.4 MB html string)

Comment 2

[Cacycle]

Attachment: Testcase (inserthtml of 1.4 MB html string)

Comment 3

[Cacycle]

As far as I could figure this out, the insert time is not related to any specific html element or part of the testcase string. It seems only be related to the number of html code tags. 

Sometimes the inserted text in the testcase is not displayed (that seems to be another bug) and when saving the testcase after it ran also saves the displayed run time, even if this was dynamically inserted by the script (clearly another bug).

Comment 4

[Ria Klaassen (not reading all bugmail)]

Can you retest with the latest trunk nightly build? For it seems significantly improved.
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/

Comment 5

[Cacycle]

Minefield/3.7a1pre gives the same insert time as Seamonkey 1.1.18 of less than a second. That is about 15-fold faster than FF 3.5.3! 

Does anybody know the bug number where this has been fixed and if it will be fixed in the upcoming FF 3.5 releases?

(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20090927 Minefield/3.7a1pre (.NET CLR 3.5.30729))

Comment 6

[Ria Klaassen (not reading all bugmail)]

Personally I don't know the bug number. It is not likely that it still will be fixed for the next version of Firefox 3.5, but it is already fixed for the next release, Firefox 3.7.
Resolving WORKSFORME.

Comment 7

[Cacycle]

As this essentially makes the Wikipedia editor wikEd unusable (at least for longer articles) I would like to have this fixed as soon as possible, which probably means in one of the upcoming 3.5 releases.

Comment 8

[Matthias Versen [:Matti]]

That means you have to find the bug that fixed the issue and nominate the fox for the Gecko 1.9.1 branch.
verified wfm

Comment 9

[Cacycle]

It has been fixed in Namoroka/3.6a1 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1) Gecko/20090806 Namoroka/3.6a1 (.NET CLR 3.5.30729))