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)
Core
DOM: Core & HTML
Tracking
()
VERIFIED
WORKSFORME
M18
People
(Reporter: elig, Assigned: akkzilla)
References
()
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).
Reporter | ||
Updated•25 years ago
|
QA Contact: sujay → elig
Reporter | ||
Comment 1•25 years ago
|
||
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.)
Reporter | ||
Comment 2•25 years ago
|
||
Per akkana's comment in 21857, please note that pasting directly into Composer
didn't work on Linux, either.
Assignee | ||
Updated•25 years ago
|
Assignee: beppe → akkana
Target Milestone: M13
Assignee | ||
Comment 3•25 years ago
|
||
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 | ||
Updated•25 years ago
|
Assignee: akkana → pinkerton
Assignee | ||
Comment 4•25 years ago
|
||
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.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Comment 5•25 years ago
|
||
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.
Updated•25 years ago
|
Priority: P3 → P1
Summary: Copying large tables hangs Seamonkey → Copying large tables hangs Seamonkey (clipboard too naive)
Comment 6•25 years ago
|
||
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.
Updated•25 years ago
|
Summary: Copying large tables hangs Seamonkey (clipboard too naive) → [feature] Copying large tables hangs Seamonkey (clipboard too naive)
Reporter | ||
Updated•25 years ago
|
Summary: [feature] Copying large tables hangs Seamonkey (clipboard too naive) → [feature] Copying large content streams hangs Seamonkey (clipboard too naive)
Updated•25 years ago
|
Target Milestone: M13 → M15
Comment 8•25 years ago
|
||
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.
Comment 9•25 years ago
|
||
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
Updated•25 years ago
|
Whiteboard: 3-4 days?
Comment 10•25 years ago
|
||
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
Reporter | ||
Comment 11•25 years ago
|
||
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.
Comment 12•25 years ago
|
||
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
Reporter | ||
Comment 13•25 years ago
|
||
[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.]
Comment 15•24 years ago
|
||
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
Comment 16•24 years ago
|
||
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?
Comment 17•24 years ago
|
||
changing severity to critical, adding perf/crash keywords, changing component to
DOM, reassigning to jst, clearing target milestone, cc pinkerton
Comment 18•24 years ago
|
||
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
Comment 19•24 years ago
|
||
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
Updated•24 years ago
|
Status: NEW → ASSIGNED
Comment 20•24 years ago
|
||
assigning to kin for debug
Assignee: beppe → kin
Status: ASSIGNED → NEW
Target Milestone: Future → M19
Comment 21•24 years ago
|
||
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
Comment 22•24 years ago
|
||
*** Bug 48894 has been marked as a duplicate of this bug. ***
Comment 23•24 years ago
|
||
*** Bug 32334 has been marked as a duplicate of this bug. ***
Comment 24•24 years ago
|
||
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
Comment 25•24 years ago
|
||
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.
Comment 27•24 years ago
|
||
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
Assignee | ||
Comment 28•24 years ago
|
||
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
Comment 29•24 years ago
|
||
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
Comment 30•24 years ago
|
||
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.
Assignee | ||
Comment 31•24 years ago
|
||
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
You need to log in
before you can comment on or make changes to this bug.
Description
•