Doing a copy (or autocopy on linux) on large documents is very slow, because the output system has to ask each piece of content if it is in the selection. This causes serious selection performance problems -- see bug 49772

Adding kin@netscape.com to Cc list.

This will probably all be radically changed for the better very soon. Cross your fingers!

m19

Since I think this is what I saw in the profile on bug 49772, nominating for dogfood. Changing to All/All, although I would think it's more serious on X11 than elsewhere.

To make the dogfood-plus/minus call, we need to hear "how slow" very slow is, and how large the document needs to be. This would only stop regular dogfood use if the email that arrives was "very large" and the slowness to reply was long enough that it would feel like the app had crashed (probably in excess of a 10-30 second delay). If the size of the email was extraordinary, then it certainly wouldn't be common enough to stop dogfood use. Performance problems have to be VERY bad before they stop folks from eating the dogfood.

if bug 43008 is fixed, then this will not be an issue, if that is not resolved, then this is a must fix

this was a break out of bug 49772, if you need specific data about size, timing, etc, go to that bug. However, please note that if bug 43008 is resolved, this particular bug will probably be resolved as well I would prefer to see this as rtm+ and not dogfood

Bug 43008 is not even nominated for beta3 (and hence not for Nav 5 rtm). This does seem like a terrible bug, based on the timing in the related bug, and could clearly stop a person from using Nav 6 if there was any need to select (cut/paste). Marking dogfood-plus.

Bug 50742 will resolve this, and it's marked as rtm++. Marking dependency. If that bug doesn't land, then this one will probably need to be addressed separately.

requesting this bug be marked as dogfood-, since this is dependent on the noxif bug which is going in as rtm

It sounds like this bug is really waiting for 50742 to resolve. Do you want to nominate that bug for dogfood to replace this one (which was bad enough to be a plus). Beppe: You asked that this bug be downgraded. Is is better now?

Akkana, please include the required information per the rtm checkin rules

No more to add than what has already been said.

PDT marking rtm-. Renominate if not fixed by bug 50742

This is not fixed by 50742, but it could be (I think) with a little more work. I'm working on it now. This is a very important bug for our linux story, as linux selection is still dominated by our very slow copy implementation. When selecting locks up the app for 30+ seconds (common on linux), we are well into stop ship territory...

Joe, putting back to need info, if this entails a massive amount of work, thenlet's put this till past rtm and make it a high priority for that timeframe

Joe has a fix which greatly speeds this up: copying 2 lines in the lxr page for nsHTMLEditor.cpp goes from 15 seconds to 5 seconds (on my 450MHz linux box), and the output system part seems to be less than a second; the other 5 seconds are spent somewhere else. Joe's fix looks like it'll help a lot!

should land tomorrow....

fixed by noxif landing

Marking verified in the Oct 24th build.

Verified again in the 2001010209 build.