12508 - [PP] Large text block won't copy ("unknown" clipbrd content)

Status: VERIFIED DUPLICATE of bug 9670

(Core :: DOM: Editor, defect, P3)

Description

[Eli Goldberg]

* TITLE/SUMMARY
[PP] Large text blocks can't be copied (yields "unknown" clipboard content on Mac
OS)

* STEPS TO REPRODUCE
0) Launch Apprunner
1) View the http://slip/projects/marvin/copy-paste/copy-large-text/
longtextpage.html file of the copy-large-text test case. (an ~800K text file with
light formatting)
2) Select the full page content.
3) Select "Copy" from the Edit menu.
4) Go to the Finder, and select "Show Clipboard" from the Edit menu. (noting that
"Paste" is disabled)

* RESULT
 - What happened

First, the copy takes nearly 30 seconds on a 266 Mhz G3, as opposed to a split
second on Navigator 4.5 on a 233 Mhz G3. But that's not what the bug report is
about.

Next, the Clipboard content type is "Unknown"; if you try to paste it into
BBEdit, nothing is pasted (or, the most results of the prior TEXT Copy operation
are pasted within BBEdit.)

(On Linux, the copy appears to happen --- terminal window says "Copying >>>>>>>>>
Wrote Clipboard to cache file, but the paste output is empty.)

 - What was expected

Behavior equivalent to Windows builds; user should be able to successfully copy
and paste large text strings.

* REGRESSION

 - Occurs On
        Mac OS Apprunner (8.24.99 AM M9 build)
        Linux Apprunner (1999082513 build)

 - Doesn't Occur On
        Win32 Apprunner (8.24.99 AM M9 [NT 4, Service Pack 3])
        Navigator 4.7 M2-ish candidate (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 SP3.

- [Linux] Vectra VL (266 MHz P2), 96 MB RAM. Red Hat Linux 6.0 (GNOME).

Comment 1

[Eli Goldberg]

[oops; forgot to set this to Editor.]

Comment 2

[Eli Goldberg]

[Reassigning to Pinkerton per his request. Thanks, Mike!]

Comment 3

[Mike Pinkerton (not reading bugmail)]

my first guess is that it's running out of memory and silently failing.

accepting bug.

Comment 4

[Mike Pinkerton (not reading bugmail)]

marking m12.

Comment 5

[Mike Pinkerton (not reading bugmail)]

i'm amazed this didn't just crash for you. there is a problem when the data size
gets to big where the transferable tries to read in the data from disk and it
fails on macOS. Usually, this would just crash because we weren't expecting a
null pointer. Guess you got lucky. Anyway, dagley already has this bug, marking a
dupe.


*** This bug has been marked as a duplicate of 9670 ***

Comment 6

[Eli Goldberg]

Verifying as duplicate. Thanks for checking!