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 firstname.lastname@example.org to Cc list.
This will probably all be radically changed for the better very soon. Cross your fingers!
Status: NEW → ASSIGNED
Target Milestone: --- → 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.
OS: Mac System 8.5 → All
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.
Whiteboard: [NEED INFO]
if bug 43008 is fixed, then this will not be an issue, if that is not resolved, then this is a must fix
Priority: P3 → P2
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
Whiteboard: [NEED INFO][see 43008] → [see 43008]
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.
Whiteboard: [see 43008] → [see 43008][dogfood+]
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.
Depends on: 50742
requesting this bug be marked as dogfood-, since this is dependent on the noxif bug which is going in as rtm
Whiteboard: [see 43008][dogfood+] → [see 43008]
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
Whiteboard: [see 43008] → [see 43008][rtm+ NEED INFO]
No more to add than what has already been said.
PDT marking rtm-. Renominate if not fixed by bug 50742
Whiteboard: [see 43008][rtm+ NEED INFO] → [see 43008][rtm-]
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
Whiteboard: [see 43008][rtm-] → [see 43008][rtm need info]
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!
Assignee: akkana → jfrancis
Status: ASSIGNED → NEW
should land tomorrow....
Status: NEW → ASSIGNED
fixed by noxif landing
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
Marking verified in the Oct 24th build.
Verified again in the 2001010209 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.