From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.0 (X11; Linux i686; U;) Gecko/20020408 BuildID: 2002052918 when attempting to paste html, text, or anything else into form elements( a textarea in this case) from an application outside the mozilla browsing interface( the html tab of mozilla composer, in this particular case) nothing happens. Ctrl keys dont work, nor does using the edit menus, or right clicking, or any combination thereof. Reproducible: Always Steps to Reproduce: 1.open Gedit or abiword, and copy some data 2.go to an online form with a textarea input 3.attempt to paste into the textarea Actual Results: absolutely nothing Expected Results: pasted the data on the clipboard into the textarea while i am hesitant to call this a major bug, I do think that the priority ranks above normal. many people compose html in editors to be pasted into message board signatures, commerce applications, and so on. *** I have not tested this in KDE yet(i use gnome). I will try it and make an addendum if neccessary
did you try middle-click? middle-click to paste selection is the only universal "paste" available in X.
I have now tested this on other websites and the behavior is the same.
Please try middle click to paste.
Something odd. When this works when pasting a small amount of text (about 20 lines) from Open office 1.0. But from Star Office 5.2 several pages of text can be pasted. Might be similar to the 4k byte paste bug
==> default owner
Assignee: matti → asa
QA Contact: imajes-qa → asa
I'm using buildid 20030109 on solaris 8/sparc with sun's gnome beta 3. I can reproduce this fairly reliably. I started gedit, entered some text into it, and tried to paste it into a mozilla textarea (this "additional comments" widget). Small amounts of text can be pasted reliably, but with larger amounts mozilla seems to freeze for a moment--the textarea cursor stops blinking--and then goes back to normal without any text appearing. I decided to do some more formal tests. I created a test file containing 256 numbered lines (total 8084 characters), then started a copy of gnome-terminal and good ol' xterm. In each of these I'd start "tee test.out | wc" to capture what was pasted and get a line/character count. Finally, I'd cut & paste two different ways: a) Copy in gedit via Edit->Select all, then paste via the center mouse button. b) Copy using Edit->Select all and Edit->Copy, then paste via the keyboard "Paste" button. Here's what I got: > wc -lc test* 256 8084 test.txt 179 5633 test.txt-gnometerm-menu 191 6036 test.txt-gnometerm-mouse 256 8084 test.txt-xterm-menu 246 7766 test.txt-xterm-menu-2 (second attempt) 256 8084 test.txt-xterm-mouse 246 7766 test.txt-xterm-mouse-2 (second attempt) Finally, I started another copy of gedit on a different host (remotely displaying to my desktop) and tried copying the test text between them. After selecting text in the local gedit, the first paste into the remote gedit would only paste 2 1/2 lines. Performing a second paste would paste about 128 1/2 additional lines. This behavior was identical no matter which text-copying method was used. Finally, I cat'ed the test text into an xterm instance, set the xterm font to "unreadable", dragged the window so that all 256 lines were visible, selected the whole thing, and tried to paste into mozilla. Mozilla pasted the entire thing without losing any text. I performed a similar test using konsole, KDE's terminal app, and with gnome-terminal. Mozilla could receive pastes from konsole fine, but pasting from gnome-terminal acted like pasting from gedit; the cursor froze for a moment and nothing was pasted. Last but not least, I can paste from xterm to kde or xterm to gedit without losing data, but xterm to gnome-terminal loses several lines. My conclusion from all of this is that gnome software has a cut & paste problem, not mozilla.
There haven't been any further comments. Resolving WFM based on comment 6.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.