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