Closed Bug 132979 Opened 23 years ago Closed 18 years ago

Pasting with mouse (X11) is slow and unreliable

Categories

(SeaMonkey :: General, defect)

x86
Linux
defect
Not set
major

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: Stephan.Fuhrmann, Unassigned)

References

(Depends on 1 open bug)

Details

Hi there, whenever I try to paste an URL from a different X11 window (or even other Mozi window) to the Mozilla window I experience that the pasted text sometimes NEVER appears, and sometimes it appears after a moment. This behaviour is not ok and it really is a major drawback of using Mozilla :(.
I just want to add what I understand of a "mouse paste" on X11. 1.) Mark a text region in a X11 console / text window with LEFT BUTTON 2.) Move mouse to destination window and activate it 3.) Push MIDDLE BUTTON to paste the marked region into the destination window
wfm.. I never noticed that cut'n'paste is to slow or fails.. and i'm running mozilla on a 200mhz pentium pro.. (Xfree 4.2)
Stephan: Is this related to the amount of text you paste? (There's bug 56219 about being unable to paste over 4000 bytes. 4000 bytes is around one page of text)
Stephan, what build are you using?
I'm using Build ID 2002031008, it's MOZILLA release version 0.99. The problem existed in all versions before. The amount of text pasted is independend of the problem, usually I paste URLs to the URL textarea or the browser window itself. The problem appears sometimes more, sometimes less intense. I'm running an ATHLON 1200, so CPU horsepower shouldn't be the problem ;). My X Server is XFree86 v4.1.0. But it shouldn't be the problem: Pasting to another window than Mozillas is ok. Maybe this helps you guys with your good work.
Just one note about Mozi's activity while having the problem: top says CPU%=2.3, MEM%=20 ... that's not unusual load i think (total of 256 meg ram, 1 gig swap). SIZE shows 146M (wow!), RSS 50M and SHARE 17184. There are 7 browser windows open. I believe the longer it runs, the better are chances to get the problem.
Are you running KDE? KDE's "klipper" app can interfere with mouse selection (though it usually causes more problems on copy than on paste). Other than that, I don't know what the difference might be -- I haven't noticed any problems middlemouse pasting on any of my machines.
My window manager is fvwm2 2.4.0 - i dont't like bloated fat applications with lots of useless functions and lots of bugs. Maybe fvwm2 is the problem? Don't know who's responsible for the X11 copy & paste story: The window manager and/or X11?
X handles copy/paste, not the window manager. I don't know why you're seeing this and nobody else seems to be ... maybe there's some klipper-like daemon running on your system?
Just one further comment which might be of interest. I'm experiencing the following problem with Nedit which is a Motif application: When copying via keyboard shortcut the copying sometimes doesn't work (clipboard has old buffer contents). Pressing CTRL-C another time works. Ok, Motif is nasty stuff and even did weird things under Netscape 4.7, but maybe I'm the only one with this problem. I don't know how this problem is related to Mozilla's problem, but maybe some of you see a similarity here or can even point me to the source of the Nedit problem which may solve this Mozilla bug thread. But I believe Mozi doesn't use good olde Motif anymore, so I'm curious what you think?
I am seeing problems too. When I am trying to copy from nedit to a form field in mozilla is the most occuring example. (Again nedit, can motif be a problem?) I first select the text in nedit. Then go to the moz window, and press middle mouse on the form. Sometimes mozilla locks for a second, and then nothing happens. Just presing the middle button can help, but not always. I am using XFree86 Version 4.1.0.1 with Enlightenment version 0.16.5
> Again nedit nedit has a known bug. Sometimes it completely forgets it owns the selection. An app will ask it for the text and nedit will just completely fail to respond. As a note, this breaks any synchronous clipboard impls that don't time out (which is why Mozilla's impl times out).
Fine that someone else sees problems, too. I just want to add that I have problems with pasting from Mozi to Mozi. Boris, your comment about Mozi's clipboard stuff times out sounds like a good point. Is there other code in Mozi (for example keyboard) that times out?
Not that I know of... There's a bug to make the clipboard asynch and remove the timeout, but it's way on pinkerton's back burner. :(
Stephan Fuhrmann: can you still reproduce this with a recent Mozilla version (like 1.0RC3)? If not, mark this bug "worksforme"
The problems still exist for me in 1.0RC3 (build id 2002052309).
there is bug 78928 about noe being able to type in dialog fields with twm and siblings. Could be related. The trick to get it working is: NOT setting "NoTitleFocus" but DO set the "DecorateTransients" option (in the window manager's rc file). If this wasn't already how your wm was configured: does unsetting/setting these options change anything?
Speed seems to be improved a lot under 1.0 release (build 2002052918), and the problems seem to have disappeared. I tried it for some days. I'll put the status to "WORKSFORME", but maybe I'll come back some day and complain again ;).
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Ok, I just compiled version 1.0 of Mozilla completely new for my Linux version since I suspected the standard build to interfere with something on my system. The problem still exists. I think it heavily depends on Mozilla's hunger for memory and big latencies when pasting. So Mozilla really forgets paste operations after a while. But people - I'm NOT pasting with my mouse for fun so Mozilla can forget the paste operation, I really want the pasting to happen.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
This is basically bug 84973
Boris: so dup?
depends, for now.... this _could_ be a separate issue (though I doubt it).
Depends on: 84973
Boris, I can't tell you if it's dup or not. On my system, Mozilla is acting strangely in some situations, especially 'pauses' are usually in sometimes.
Right. All I'm saying is that until bug 84973 is fixed it's very hard to evaluate what's going on here...
I also get it frequently. Linux 2002102804, Mandrake 9.0, XFree86 4.2.1, IceWM, no KDE, also the nedit problem described above, and the copy/paste bug: -Sometimes I paste the text and Moz hangs for 1 or 2 seconds. Then, nothing occurs. I try it another time, and the same behavior. After some tries, I can paste. (I usually copy the text again and then it works). -It happens with the URL bar, text fields, TEXTAREAs, etc. With everything. Could it be that this behaviour were produced because I am moving a bit the pointer just after having middle-clicked? (And doing a paste/drag&drop at the same time). I haven't tested it completely...
Still exists in build 2002102521. It may be <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=84973">bug 84973</a>, so let's wait if someone fixes the async clipboard bug. I have the impression that this behaviour also applys to all other user input like key hits etc, but there I only see a slight delay between key hit and char display (nothing gets lost).
Confirming at least. I've had these problems with mozilla for ages now and they seem to be getting worse. I can't even reliably paste from mozilla to mozilla (for instance, browser to mail).
Status: UNCONFIRMED → NEW
Ever confirmed: true
I don't see this problem, I'm using "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030430" In fact I just did a mouse cut and paste to paste my user-agent string in.
One year has passed.. Can someone confirm that this bug still exist?
Yes, this bug is just fine. In fact, it can't get better until bug 84973 is fixed.
Product: Browser → Seamonkey
Assignee: asa → general
QA Contact: doronr → general
I have not seen the effect on any of the platforms I use for a long time, so I suspect that it disappeared as the side effect of another change.
Status: NEW → RESOLVED
Closed: 23 years ago18 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.