Bugzilla Bug 239045

You know you can select text with your mouse and can paste it with the third
mouse button (or else).
But if I select a terminal in X (or any editor) switch to a "real" console and
back, then this paste command was executet. With other words I see the
mouse-selected text now in my editor...
Nearly a security bug: Maybe you have a root terminal and you marked "rm -rf
*", then you delete the whole system...
I had this bug on my old x86 and my new amd64 system.

Reproducible: Always

Steps to Reproduce:
1. Mark some text with your mouse (better not a command for a terminal...)
2. Open a terminal (not root) or editor, make sure your mouse-coursor is in a
position to enter text
3. Switch to a "real" console (Strg-Alt-F1,...)
4. Switch back to the Xfce (not tested with kde or gnome or others...)
5. You shoul see now your marked text in step one in your editor / terminal.


Expected Results:  
I expect that switching not execute the paste of the mouse "memory"

I set this to critical, because it causes me to lose data. (with this worst
case scenario: mark "rm -rf *" and switch back to a console...

What key combination do you use to return to the X terminal?

Hi there, I use:

Alt-F7

And this doesn't happen without xfce-base/xfce4-4.4.2, like with a completely
different window manager or a different version of xfce?

I installed kde 3.5.9. (sry, this take some time on gentoo ;-) )
This problem holds with this windows manager.
And it occurs in the "failsafe terminal".
Ok, this is not only a xfce problem.

Doesn't try another version of xfce beacause there is no ebuild in the protage
(Yes I know, I can look here or write it myself, but I do it only if necessary)
and gnome want to install to many software...

Hint: I don't think its a driver problem with my ati card because my old system
had a nvidia card... In both cases I use the propritary driver.
The fraembuffer driver is on both systems uvesafb, I don't know if this is
relevant.

It's more likely to be a problem with the server itself or with the input
driver.

I have a similar problem (xorg-server-1.5.1 and xf86-input-evdev).
While it doesn't paste anything for me, it sends Fn to the terminal,
when switching with Alt-Ctrl-Fn.

Ok, then its time to offer more information:

I use a laptop / notebook. German keyboard layout:
*************************
Section "InputDevice"
        Identifier  "Keyboard0"
        Driver      "kbd"
        Option      "CoreKeyboard"
        Option      "XkbModel" "pc105"
        Option      "XkbRules" "xorg"
        Option      "XkbLayout" "de"
#        Option      "XkbVariant" "nodeadkeys"
*************************
I use
xorg-server-1.4.2
xf86-input-keyboard-1.3.0
xf86-input-mouse-1.2.3

and xf86-input-evdev is not installed!

OK, so having a German layout, do you happen to use AltGr-F7 (as opposed to
Alt-F7) to switch consoles?

I use XkbVariant "nodeadkeys" now. Probmel holds. With AltGr-F7 I cannot switch
consoles. Nothing happens (only in X, but thats normal...).

You ask all this, do you have any idea of a direction where the failure is?

Could you check if you can reproduce it with evdev driver
(cause the problem is probably somewhere between input driver and the server) ?

(In reply to comment #8)
> I use XkbVariant "nodeadkeys" now. Probmel holds. With AltGr-F7 I cannot 
> switch consoles. Nothing happens (only in X, but thats normal...).

Could you run xev (x11-apps/xev) in X in the foreground and then do the console
switch?

> You ask all this, do you have any idea of a direction where the failure is?

Certainly. :)

Created an attachment (id=167094) [details]
back switch, copy from terminal

First test: started xev, switched to console and back to X. Interesting: 
It seems to me the paste was not catched: "inux@Targa1526" was the marked text
and was paste in the terminal.
Hint: I had to copy this from the console, hence it is only a cut-off.

Created an attachment (id=167095) [details]
xev > xev.txt

Same procedure, but now with "xev > xev.txt".
The problem is that I have to stop xev with moving mouse and "Ctrl-C". Hence
the last entries are not from switching. Don't know to find out which is the
right.

The test with evdev needs some time (had some problems with it, X Server did
not want to start) and now I have to leave my internet and go to a habitation
without internet for the weekend :-( ...

I don't test evdev yet, but I found this:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/276887

Fixed with evdev 2.0.6

I believe it could be a bug in xf86-input-keyboard/mouse, similar to the evdev
bug... 

Now I try to update xf86-input-keyboard to 1.3.1 and -mouse to 1.3.0
Then I try updating X with and use newest evdev (in portage, 2.0.5).

If the bug says: "fixed in 2.0.6" why do you think 2.0.5 will make
a difference ?

Thanks, now we can finally put a package and maintainer to this problem! :)

(In reply to comment #15)
> Thanks, now we can finally put a package and maintainer to this problem! :)
> 
NO! I said I DON'T use evdev, it is not installed at all! I only want to make
clear there was a similar problem. And as I read, it is NOT exactly the same
bug (I don't need to type anything on the console and so on). Maybe the
developers make similar mistakes...

Because of this I think:
If I test evdev-2.0.5 and I have not exactly(!) the same bug (or I can test
2.0.6, but it is not in portage yet), then xf86-input-keyboard/mouse has the
bug.

*sigh*

x11-drivers/xf86-input-mouse is the right package! Reason:

Update keyboard to 1.3.1 and mouse to 1.3.0: bug fixed!
Downgrade back the mouse driver to 1.2.3: bug is there!
Update mouse back to 1.3.0 and downgrade keyboard back to 1.3.0: bug fixed!

It follows the input-mouse driver was affected.

Now its your turn Jeroen, you can post your commit 15 again ;-)

Hi,
I use x11-drivers/xf86-input-mouse-1.3.0 and keyboard-1.3.0 since 6 days on
amd64 with no problems.
Voting for unkeywording (of both) in portage because of the bug in mouse-1.2.3
and then closing this bug.

Stabilization is getting closer, this bug should be fixed when 1.5.3-r2 and
friends hit the stable tree.

Thanks

1.5.3-r5 is now stable, closing.

Thanks