Using a Win32 commercial build from 09/05. When trying to fill out bugzilla reports, the time it takes for a typed character to show up in the description field of a bug just got MUCH worse. On my PII 500Mhz with 256MB of RAM, I'm experiencing delays of up to 1 second per character. This is with a release build. It definetly didn't used to be this slow.

Nominating for beta3 on the grounds that this recent performance regression makes text fields really hard to use. Even on my high end system it hurts. I suspect a target machine with less RAM is really going to unuseable. Note: this bug is to track my perceived recent perfromance regression in text fields and NOT general performance improvements to text input.

someone made a checkin between Friday and today that really hurt performance, this needs to be tracked down, if someone has the time to help it would be great

assigning to mjudge, setting to m19 where perf work is being done

I'm leary about the beta3- nomination this bug was just given. The regression is *really* severe. cc'ing pavlov who mentioned that he noticed extra painting going on when typing in text fields on IRC the other day.

re-nominating for beta3 and marking blocker. I can't use the linux client because of this.

performance is being addressed in m19, which is next. marking +, adding akkana, kin & sfraser

sweet a p2! let me at it..

turn on paint flashing. try typing in bug submission form... bad the entire page repaints. I think buster took a hack at a similar problem for enders not in a table. This particular entry field IS in a table which is handling the incremental reflow quite badly.

PDT agrees P2, but on current Win32 builds, it doesn't seem so bad.

see bug 39885 for reference. that bug was fixed but did not take into account of colspan on the cell that contains the text field/area. in the posted attachment 51392bad.html simply remove the colspan on the text area cell and the whole table will not repaint on each input. I will reassign this to karnaze. He says he can look at this by tomorrow. after our little deadline here. i am hoping that if the fix is simple enough we can still check it in since this really hoarks typing on certain web pages. recommend PDT please make this P1 with dependency on simplicity of fix.

Fixed the summary to not look like yet another "boo-hoo typing speed is bad" bug. Nominating dogfood, since submitting bugs is a particularly common task for us :) Also: this probably isn't a windows-only bug. Do we have this problem on linux/mac?

Yep, slow everywhere, particularly linux.

PDT: recommend that this is a fairly major XP problem which ought to get cleared up by some minor layout voodoo. Like mjudge said: recommend P1 contingent upon simplicity of fix.

There are statements that this is terrible on Linux, and also statements that this is terrible on Windows. I'm using the 9/20 build, as I'm entering this text, and mozilla is *completely* keeping up with me (i.e., I don't see *any* delay from typping to appearance of characters). Unless we mark this as a linux only bug... I can't justify claiming this is dogfood. I suspect that the problem has been fixed. Linux users: If you are still seeing the dramatic regression, please marke the bug as such (Linux only (or is this Mac also??)) and renominate for dogfood.

Everyone who makes comments on performance bugs should give their CPU speed before giving their observations.

oops... my bad... sorry I left out my machine details... 300Mhz Laptop, Running NT, and the 2000092005 build from (Netscape) Sweetlou I have 256Megs of memory... and the performance typing bugs is excellent (and incase it matters... I'm using the New Modern skin) The original bug report was on a 500Mhz box, which is what lead me to suggest this is at least partially fixed

I promised mjudge that I would look at this last Friday. The fix seems very low risk and eliminates unnecessary table re-balancing when text is entered in cell with colspan > 1 (colspan = 1 was not a problem). The more cells in the table, the more pronounced the effect. I could construct a test that would be much worse than the bugzilla page. I don't think this is a recent regression in the table code (it looks like this problem has been around a while).

r=buster this is an extremely high value fix for dogfood, and is very low risk. I think we must get this in for rtm. If we are taking any fixes for beta3, I would consider taking this one.

*** Bug 53594 has been marked as a duplicate of this bug. ***

*** Bug 50065 has been marked as a duplicate of this bug. ***

PDT: recommend P1 and ++ based on simplicity of fix (in hand). if not now, then certainly for RTM.

Adding rtm+ to status whiteboard.

PDT looking for nsbeta3++ bugs, and not sure what to do with this one. If the performance is really 1sec/char, we're sympathetic, but if it's ok enough for b3, we'd rather take the change in RTM to allow shake-out time. Any users of current Mac or Linux builds want to characterize their performance?

If posting status of this bug... be sure you're using an optmized build, and be sure to mention the speed of the machine you're on. Thanks, Jim

PDT marking nsbeta3-, would like more bake time before taking on branch.

I just installed b3 on a 266 mhz win98 box, and typing is painful!

PDT marking [rtm++] since it appears that karnaze and buster have both reviewed.

Fixed.

verified in 10/12 build.