From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+) Gecko/20020326 BuildID: 2002032603 When you try to enter some text in the TEXTAREA-field of the given URL, the printing of the text on the screen is exremly delayed. It is really horrible to use Mozilla for this page. Either with IE5/6 or NS4 it is as expected. I guess it could be a JavaScript-problem, but I do not know exactly... Reproducible: Always Steps to Reproduce: 1. open the URL 2. try to type some text in the TEXTAREA-field Actual Results: Chars entered are printed extremly delayed Expected Results: Chars are printed as fast as I write down the text time2bcool.com sometimes is veeeery slow, so it might take a couple of time until you get the page loaded.

Can't get to the page. Reporter, any chance you could attach a testcase to this bug instead?

It is slower than expected but not "extremely delayed". While it should be faster, the only thing which is actually "horribly slow" here, is the loading time of this page, very badly coded and with a lot of useless JavaScript code and graphics I couldn't load with any browser... Also, MicroSoft Internet Explorer 6 generated not less than 6 JavaScript errors on that page... probably the code which makes it slow in Mozilla is not working. On Netscape 4.79 the page loaded properly (graphics a part), and the speed of the TEXTARES is normal, but the character counter doesn't work even if it did't generate any JavaScript error, which means the same thing said above apply... On Opera 6.0 I've stopped it after more than 11 minutes and 950 Kb downloaded (and I'm on ADSL) and nothing showed on screen. I didn't investigate further, but I've noticed these lines in the code of the page: if (navigator.appName == "Netscape") { window.captureEvents(Event.KEYPRESS); window.onKeyPress = code } which makes me think could be a leading role in this case...

Attached as requested by combstm@lucklobster.com

Well, I have just added the URL as attachment. When you try the textarea there, it is not that slow like when I call the original URL. This speed now is acceptable. But when I visit the URL, typing in is like having a stonage 300bps line...

i cannot even access the original URL no matter which browser i'm using

cannot access the original url, the attachment works fine for me on windows 98... Can you please create a new reproducable testcase, or this bug will be marked invalid based on the comment #2

Well, here (from Germany) I can access the page without problems. Maybe you could try http://www.time2bcool.com/ger/CCShow.asp?CC=MozillaTest - it is the same.

Thanks! This site works. Confirming. It is very slow... but this is deifinatly not form submission. It is either CSS or Form Controls, I'll investigate further..

I tried narrowing down the bug, but every time I remove something from the page it makes it faster. There is no particular thing causing this, but a combination of everything on the page. I dont know what is the correct component for this, so I'll put it in form controls for now.

i have the feeling that the animated gifs are causeing the problem on the URL. the attached testcse works ok for me.

targeting / reassigning (this should be included in a tracking bug about the textarea bugs)

er... i'm here again, (how did that happen? :-) i heard waterson fixed a bug about textarea typing beeing slow. chris: did you? :-)

Yeah, that we the reflow root stuff in bug 135146: those changes went in on the trunk on 2002-04-10, and on the branch on 2002-04-12.

RC2/Linux - Delay well within reasonable limits. (fixed? :)

If not FIXED, then at least WORKSFORME. I visited the URL and not only do typed chars show up as fast as I can type anything intelligible (~60wpm -- though admittedly I was able to see the delay by just pushing lots of keys like a monkey banging on a keyboard jkladkljd), but I tried pasting in a paragraph and it went in instantly. WORKSFORME or FIXED, take your pick, but unless someone can step forward and reproduce it, let's get it resolved.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0+) Gecko/20020603 Load URL. Dozens of erros in the JS console. Yes, when typing in text quickly there is a noticable delay. Saved entire page to disk, loaded from disk, delay still visible. Delete most javascript from page, reload, text appears at normal speed. So some javascript on the page is the problem. Textarea code: <textarea rows="8" cols="44" wrap="virtual" name="strSendeText" style="width: 550; height: 70; " onFocus="checkFieldLength(this,700)" onBlur="checkFieldLength(this,700)" onKeydown="checkFieldLength(this,700)" onKeyup="checkFieldLength(this,700)"></textarea> The checkFieldLength() function being called so often is the likely culprit. function checkFieldLength(field,maxlength) { var anz = field.value.length; if (anz > maxlength ) { field.value = field.value.substring(0,maxlength-1); frei = 0; } else { frei = maxlength-anz; } document.forms["frmControl"].strAvailable.value = frei; } Suggest marking INVALID? Or perhaps looking at the the speed of code in Mozilla that is run when the onKeydown and onKeyup events fire? I created a simplified testcase, and while it is faster than the original page, I can still see that is is slower than a textarea without the onKeydown and onKeyup events.

i have been having this problem since version 1.0 (also on 1.1a) and downloaded the latest build (2002070608) and it's a little faster than it was but it's still noticeably slower than IE. i tested it in the debug->viewer demos->#8 form and it types just as fast as i type it in. i'd guess it's the size of the textarea (the one on the page i'm having problems with is 99% wide) but i'm also noticing every character i press it's doing something on the hard drive (it's audible as well as seeing the light flash) and this is only on the livejournal comment entry textareas, not on any others that i've seen (i haven't tested the page attached to the bug report). http://www.livejournal.com/talkpost.bml?journal=geeks&itemid=300511 that's the url, but it's the same on all livejournal comment entry pages. the most current build is alot faster than the earler (1.0 and 1.1a) builds which were about 1 character per second. i just noticed the comment i'm entering is in a large text area but it's typing as fast as i'm pushing the keys, so it's obviously only a select number of pages that have this problem. the above page only has 2 very small animated gifs but no real javascript anywhere. i'm done rambling, i hope this info helps (it took me a while to find this bug because it doesn't have the 'textarea' word, it's 'textarea-field' and i'm guessing anyone else having the same problem can't find it)

i wanted to add that i saved the page to my HDD and it still shows the same problem, i edited out the animated gifs and it still shows the same problem, so it's not those. i edited out the small (odd-looking) javascript it did have and it still has the same problem. i did notice that scrolling on the same page is jerky, too, which i'm sure is a completely different bug to report (but maybe another simptom of the same problem?). hope this helps find/repeat the problem

I think that this is just processing power! There's a counter counting down. There will be slowdown because it has to do a lot of processes every time you press a key.

This is a testcase generated from the URL in comment #18. The sluggishness of the imput seems to be related to its width; I've added a few more textareas for comparison. It looks like this one is related to the background image on the page. Getting rid of the background or changing to another background gets rid of the sluggishness in all textareas. There's something about the image Mozilla doesn't like; it doesn't display if try to view it directly (by putting its URL in the location bar). Perhaps the fact that it's 2 x 3000.

-->

The speed differences between moz1.0 and current trunk builds after moz1.1alpha, is probably due to the work done in bug 141900. There are still some pending issues filed as separate bugs, some of which were mentioned here ... bug 151682(over invalidating) and bug 94576 (Filling out form with counter is slow).

As has been mentioned before, this is a persistent problem when using LiveJournal. It continues to persist even in recent builds. Further information: I've noticed, quite by accident, that if the browser.display.use_document_colors pref is turned off, this problem vanishes. Dunno if that's helpful or not...

WFM Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030720 Mozilla Firebird/0.6 Both the test URL and LiveJournal seem very responsive.

Works for me too. The problem has been getting better and better as development progressed, and by the time 1.3a came about was pretty much gone. The version I'm using (Mozilla 1.4 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624) seems to be fine. This pleases me to no end. Except... Can anyone verify if this bug has actually been fixed (as in the code errors that caused it have been found and corrected)? I've seen this gradually fading behavior with one or two other usability bugs I've been following, and that leads me to believe that these bugs haven't been fixed but rather what's happened is the application overall has been improved to the point where the bugs are no longer noticable. That's fine...until someone does something to the application and the bug expresses again. So can anyone out there verify that this bug is dead? Or at least that it's not a dormant "retrobug" just waiting for a stressor to re-express itself? (This may seem a silly hair to split, especially from a development point of view, but from an evangelism point of view it's important. Since 1.0, Mozilla has already undergone several "regressions in functionality" and that's just not a Good Thing.)

WFM