Closed Bug 12508 Opened 25 years ago Closed 25 years ago

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

Categories

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

PowerPC
Mac System 8.5
defect

Tracking

()

VERIFIED DUPLICATE of bug 9670

People

(Reporter: elig, Assigned: mikepinkerton)

References

Details

(Whiteboard: 1 day once dependency is fixed.)

* 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).
Assignee: don → buster
Component: Browser-General → Editor
QA Contact: leger → elig
[oops; forgot to set this to Editor.]
Assignee: buster → pinkerton
[Reassigning to Pinkerton per his request. Thanks, Mike!]
Status: NEW → ASSIGNED
my first guess is that it's running out of memory and silently failing. accepting bug.
Blocks: 12669
Depends on: 12278
marking m12.
Whiteboard: 1 day once dependency is fixed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
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 ***
Status: RESOLVED → VERIFIED
Verifying as duplicate. Thanks for checking!
You need to log in before you can comment on or make changes to this bug.