Closed Bug 21847 Opened 25 years ago Closed 24 years ago

Copying large content streams hangs Seamonkey (clipboard too naive)

Categories

(Core :: DOM: Core & HTML, defect, P2)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: elig, Assigned: akkzilla)

References

(
URL
)

Details

(Keywords: crash, perf, Whiteboard: [nsbeta3-]Can't reproduce the hang) 

* TITLE/SUMMARY
Copying large tables hangs Seamonkey

* STEPS TO REPRODUCE
0) Launch Apprunner
1) Select the contents of http://slip/projects/marvin/copy-paste/copy-large-text/
longtablepage.html, and choose Copy from the Edit menu

* RESULT
 - What happened

Mac OS: After 5-10 minutes, the browser remains nonresponsive, can't change apps,
and the Edit menu bar item remains highlighted. It finally completes the copy,
but nothing goes to the clipboard.

Win32: On a 96 MB system with no other apps running, it runs out of virtual
memory after 5 minutes, and finally dies. (Talkback: probably 2520100)

Linux: "Copy" doesn't seem to be doing anything --- nothing gets pasted into a
3rd party text editor.

 - What was expected

Table to be copied successfully without a crash. Not sure if this is a dupe of
12541 or 9670.

* REGRESSION

 - Occurs On
        Mac OS & Win32 Apprunner (12.15.99 AM optimized build)

 - Doesn't Occur On
        Communicator 4.7 RTM (Mac OS)

* CONFIGURATIONS TESTED

- [Mac] Beige Power Mac G3 (266 MHz PowerPC 750), 96 MB RAM (VM on; 1 MB of VM
used), 1024x768 (Thousands of Colors), Mac OS 8.6

- [Win32] Vectra VL (233 MHz P2), 96 MB RAM, 800x600 (True Color), NT 4.0 SP5.

- [Linux] Vectra VL (266 MHz P2), 96 MB RAM. Red Hat Linux 6.0 (GNOME).
QA Contact: sujay → elig
QA Assigning to self.

Due to large-sized test case, anyone who wants this can e-mail me, and I'll
attach it to bug. (Not attaching unless needed.)
Per akkana's comment in 21857, please note that pasting directly into Composer
didn't work on Linux, either.
Assignee: beppe → akkana
Target Milestone: M13
I suspect this is probably my bug (certainly more than anyone else's in the
editor group).

Unfortunately, I can't test it right now, because SelectAll is greyed out, and
attempting to select a little at the start, then scroll down to the end and
shift-click to select everything, doesn't actually select.

Eli, how do you "select the contents of" this page?
Assignee: akkana → pinkerton
Okay, got it.  click at the beginning, shift-click at the end, then wait a
looooong time. :-)

Both the copy and the paste do finish eventually -- they just take a very long
time and the paste doesn't successfully transfer any data.

Presumably this is an out-of-memory problem with the clipboard.  Pinkerton
talked it over and agreed it's a clipboard problem.
Status: NEW → ASSIGNED
accpeting for m13. we need a total rewrite of the format converter stuff,
probably just ripping it out. cc'ing nhotta because he has changes to that stuff
waiting to go in.
Priority: P3 → P1
Summary: Copying large tables hangs Seamonkey → Copying large tables hangs Seamonkey (clipboard too naive)
marking p1, cc'ing shaver.

I'll be adding my plans on how to rewrite the clipboard/format converter api's
once i get them all straight. Now that cut/paste are hooked up everywhere,
getting this stuff preformant for dogfood is my top priority.
Summary: Copying large tables hangs Seamonkey (clipboard too naive) → [feature] Copying large tables hangs Seamonkey (clipboard too naive)
Summary: [feature] Copying large tables hangs Seamonkey (clipboard too naive) → [feature] Copying large content streams hangs Seamonkey (clipboard too naive)
[generalized title, per pinkerton's comments in bug #9670]
Target Milestone: M13 → M15
I have a couple of ideas, but I'd rather wait until postbeta 1 to do them as they
will take some time to get right. I would like to comment out the AOLMAIL flavor.
Do we _really_ need that flavor right now? That would speed things up a little.

Pushing out past beta one.
Blocks: 24206
pushing out again. i've got more important things to worry about and things have 
gotten better lately, i think.
Component: Editor → XP Toolkit/Widgets
Priority: P1 → P3
Target Milestone: M15 → M18
Whiteboard: 3-4 days?
Eli, could you test this again? (or give it to jrgm). If it stays open, we need 
to find a new owner for it.  The bulk of time spent seems to be copying DOM 
data, which we have no control over. cc'ing jst & joki
Sure, Peter. I tried using yesterday afternoon's Mac OS beta 1 branch build on 
the fastest Mac that money could buy 30 days ago (450 Mhz G4 w/256 MB RAM).

Eighteen minutes after starting the copy, the copy wasn't completed, so I finally 
killed the process so that I could get back to work.

this is probably just 12541, but let's make it a dependency since the out of 
memory might be a different problem than the slooooooooooooow content model 
translation.
Depends on: 12541
[Note to self: when verifying this bug, try a mondo-huge page and see what's in
the clipboard if it fails, like on Windows, due to a lack of memory.]


Mass moving M18 bugs to M19
Target Milestone: M18 → M19
This needs a more accurate description of the work to be done, and an estimate 
that doesn't have a question mark.  It probably still needs a new owner too.
Priority: P3 → P2
Target Milestone: M19 → M18
this needs a new owner, my work to make this faster is now broken out into bug 
39748. This should go to an editor or layout person.
Assignee: pinkerton → trudelle
Status: ASSIGNED → NEW
Summary: [feature] Copying large content streams hangs Seamonkey (clipboard too naive) → Copying large content streams hangs Seamonkey (clipboard too naive)
Whiteboard: 3-4 days?
changing severity to critical, adding perf/crash keywords, changing component to
DOM, reassigning to jst, clearing target milestone, cc pinkerton
Assignee: trudelle → jst
Severity: normal → critical
Component: XP Toolkit/Widgets → DOM Level 0
Keywords: crash, perf
Target Milestone: M18 → ---
No longer blocks: 24206
AFAIK there's no low hanging fruit in the DOM code that we could pick here (in
time for the release), reassigning to beppe for investigating if there's
something that could be done in the editor related parts of this do to increase
the performance when copying large selections...
Assignee: jst → beppe
sorry, the two dependent bugs are futured, so this one needs to be moved out 
too. We will be addressing performance issues after beta3, so hopefully we can 
bring this back in then.

This bug has been marked future, f you feel this is an error, or if it blocks 
your work in some way -- please attach your concern to the bug for 
reconsideration.
Target Milestone: --- → Future
Status: NEW → ASSIGNED
assigning to kin for debug
Assignee: beppe → kin
Status: ASSIGNED → NEW
Target Milestone: Future → M19
although the dependent bugs are futured, we should not crash -- the pasting may
not work, or the app may remain slow, but the crash should not happen
*** Bug 48894 has been marked as a duplicate of this bug. ***
*** Bug 32334 has been marked as a duplicate of this bug. ***
35229 blocked 32334, which I am marking as a dup of this -- again Kin, if this 
is not a dup please reopen
Depends on: 35229
I don't know if anyone is aware of it, but on Linux one can't paste over 4000
bytes into an editor (like when composing mail). 4000 bytes isn't even a full
normal page of text.

Pasting 4000 bytes goes fine. Pasting 4001 bytes and above will freeze
everything. That renders composers in moz pretty much totally useless for me for
any real work.
Passing to akkana who handles editor copy/paste.
Assignee: kin → akkana
Nominating for nsbeta3.  It doesn't sound like the dependencies have anything to
do with a freeze, are any of them really required in order to fix this?  I know
that promises are one way to make this better, but we should still be able to
paste 4K without them.
Keywords: nsbeta3
I just pasted 56019 characters (the full text of nsHTMLToTXTSinkStream.cpp,
which happened to be handy) from emacs into a blank Composer page on my Redhat
5.2 system.  It wasn't fast, but it finished and now I can type in the window
and everything works.

How do I reproduce this?
Whiteboard: Can't reproduce the hang
we are able to paste, slowly, but it does paste. The slow performance is 
actually being addressed in m19
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Whiteboard: Can't reproduce the hang → [nsbeta3-]Can't reproduce the hang
What is meant by "slow" here? Trying to paste 4001 bytes w/middle mouse click or
edit/paste into composer: After 3 minutes on a P3/500 still nothing was pasted.
Crash/hang is gone, so this bug is WFM, but some serious 4000byte limit remains.
Closing composer at this point doesn't prompt to save either, indicating nothing
even happened.
Sorry for the spam!  But apparently all these closed bugs need to have their
target milestones changed since M19 and M20 are going away.  Since they're
allready closed, I'm choosing M18.
Target Milestone: M19 → M18
Verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.