Version: unspecified (using KDE 4.6.2) OS: Linux When I paste text into krunner it goes back one step in history as if I pressed Cursor Up key and then pastes the text into its input field. Reproducible: Didn't try Steps to Reproduce: - Alt-F2 - type: true - copy "false" into your clipboard - Alt-F2 - paste "false" into KRunner Actual Results: Somethine like: trufalsee Expected Results: Should be: true KRunner will go back in history when you paste further times. This did not happen with KDE 4.4. I think it already happened with KDE 4.5. Currently I am using KDE 4.6.2 from Debian experimental packages together with Qt 4.7.2 from Debian unstable packages. The bug is rather annoying cause it renders pasting into KRunner nearly useless. The bug also happens in Konqueor's URL field, but it does *not* happen in Rekonq's URL field. So this might be a lower level problem, but I am not sure where to report this. Stuff reported to "kde/general" seems to go to unassigned bugs like Bug 255777 - copy and paste broken, where it doesn't seem to get much attention.
Well this is *always* reproducible. Seems I didn't to get to enter this into the guided reporting form.
See also: Bug 272037 - when pasting url into konqueror url field it goes back in history and pastes the text then
It seems this has to do that it is possible to cycle through the history of the KRunner input field by clicking the middle mouse button, the mouse wheel. But the middle mouse button should just paste. One can still cycle through the history rolling the mouse wheel up and down.
Hmmm, with some recent update of Debian packages, all built from source package kdebase-workspace 4:4.6.2-2 (instead of -1), among them, this now works for me. Closing as WORKSFORME as its not known whether root cause has been fixed.
Well now this again happens. Thus reopening. I don't know why it worked for some time before.
This is the correct behavior. You simply do not understand how select/paste is different from copy/paste. See the explanation in bug 255777
Dawit, I know that there is a difference between Ctrl-C/X and selecting text with the left mouse button. I think you misunderstood me: I try again: Steps to Reproduce: - Alt-F2 - type: kwrite - in kwrite type "mytext" and select it via left mouse - middle click on the kwrite text pane - "mytext" is inserted - Alt-F2 - KRunner opens again with an empty input field - middle click on the empty input field to paste "mytext" again just like it worked before in kwrite Actual Results: Somethine like: kwrimytextte Expected Results: Should be: mytext I hope this is more clear. Thing is the input field is *empty*, I have "mytext" in the middle click text buffer / clipboard as demonstrated by pressing middle mouse button in kwrite window. Thus "mytext" should be pasted into KRunner input field and thats it. Instead KRunner first steps one step back in history back to "kwrite" and *then* pastes "mytext". Ok, so as clear as it gets: Pressing middle mouse button on the KRunner input field steps back in history like cursor up and then pastes the text instead of just pasting the text. Or maybe even: Pressing middle mouse button goes back in history is the real problem here. This does not happen directly after login but after a while of session usage. And it did not happen with KDE 4.4, I am not sure about KDE 4.5. Thus I think thats a real issue and not me understanding something correctly. I hope this is more clear, Dawit if you do not understand yet, what I mean, please ask back instead of closing the bug report. Thanks.
(In reply to comment #7) > Dawit, I know that there is a difference between Ctrl-C/X and selecting text > with the left mouse button. I think you misunderstood me: > > I try again: > > Steps to Reproduce: > - Alt-F2 > - type: kwrite > - in kwrite type "mytext" and select it via left mouse > - middle click on the kwrite text pane > - "mytext" is inserted > - Alt-F2 > - KRunner opens again with an empty input field > - middle click on the empty input field to paste "mytext" again just like it > worked before in kwrite > > Actual Results: > Somethine like: kwrimytextte > > Expected Results: > Should be: mytext > > I hope this is more clear. Ahh... now it is clear. My bat for not understanding what you were actually trying to say. However, I still cannot reproduce the problem here on my machine and this current session has be running. I tried multiple times and with multiple applications (Krunner, Konqueror, kwrite, etc). My question to you now is, is kclipboard enabled and running on your system ? If so, does disabling temporarly or otherwise fix the problem ?
Dawit, no problem, I didn´t describe it clear enough for the Konqueror case. Do you mean klipper? It was running. I quit it and Konqueror, so that no konqueror processes were running. I open konqueror again and pasted something into the empty URL field. This worked. But on the second try to paste something into the URL field it went one step back in history again. I then quit konqueror again and start it again. Then it goes back in history on the first paste with middle mouse button. Dunno where that slight difference come from. I observed something else: - when I open the second tab, and middle click paste into the URL field, it goes back one step in history and then pastes - when I open the third tab and middle click paste into the URL it just goes one step back in history and doesn´t paste - same with further tabs I also now tested with a clean account where ~/.kde did not exist before first login. I started Konqueror, then it worked correctly, I opened http://www.heise.de, clicked some links, surfed a bit and then selected some text and pasted again: Then the URL field went also back in history on middle click. So this is reproducable with a clean account. I also have it with my company account. To make my tests complete, I stopped Klipper in the clean session, told it not to start on session start, logged out and logged in again. Then the URL field went back on the first attempt to paste something from the initial about Konqueror page. I suspect that there might be something that sets the middle click as "go back in history". But I have no idea what, no idea why in KRunner and Konqueror, but not in Rekonq, and I have no glue where to look for something like this. Any hints?
(In reply to comment #9) > Dawit, no problem, I didn´t describe it clear enough for the Konqueror case. > > Do you mean klipper? It was running. I quit it and Konqueror, so that no > konqueror processes were running. I open konqueror again and pasted something > into the empty URL field. This worked. But on the second try to paste something > into the URL field it went one step back in history again. Yep, I meant klipper :) > I then quit konqueror again and start it again. Then it goes back in history on > the first paste with middle mouse button. Dunno where that slight difference > come from. > > I observed something else: > > - when I open the second tab, and middle click paste into the URL field, it > goes back one step in history and then pastes > > - when I open the third tab and middle click paste into the URL it just goes > one step back in history and doesn´t paste > > - same with further tabs > > I also now tested with a clean account where ~/.kde did not exist before first > login. I started Konqueror, then it worked correctly, I opened > http://www.heise.de, clicked some links, surfed a bit and then selected some > text and pasted again: Then the URL field went also back in history on middle > click. > > So this is reproducable with a clean account. I also have it with my company > account. > > To make my tests complete, I stopped Klipper in the clean session, told it not > to start on session start, logged out and logged in again. Then the URL field > went back on the first attempt to paste something from the initial about > Konqueror page. > > I suspect that there might be something that sets the middle click as "go back > in history". But I have no idea what, no idea why in KRunner and Konqueror, but > not in Rekonq, and I have no glue where to look for something like this. Any > hints? Hmm... nope. There is an option in Konqueror for navigating back in history, but that is using the RMB not MMB. Moreover, that option only applies to Konqueror, but you seem to have the issue in krunner as well ; so that cannot possibly be the issue. You can also duplicate the problem with a clean account so that eliminates configuration changes or the auto completion settings for these input boxes. As such I am not sure what the cause could be, especially since I cannot duplicate the problem myself. It is entirely possible the issue might have already been fixed since I am currently running what will become KDE 4.7, but then I do not ever remember encountering the problem you describe here even in the older versions of KDE. The only MMB paste problem I ever encountered was the double pasting problem which I still encounter occasionally. Perhaps someone else who can reproduce your problem will be able to shade some light into this issue.
we'll need a clear way to reproduce this as it does not happen here running 4.7beta1
Dawit, Aaron, it was easily reproducible when logging into a new session, surfing a bit and then pasting something into the location bar. I tried today again after upgrading to 4.6.3 packages from Debian. Then I could not reproduce on the test account, also not on my private and my company account even tough I did not log out and then in again after the package upgrade. Thus I close the bug report. Should it happen again, I will reopen. Thanks
The issue appeared again. Frankly I have not the foggiest on how to reproduce it reliably, Aaron, sorry. And so far no one else seemed to be able to reproduce it. Well I reopen it but that might be it for now. Hopefully its just fixed with KDE 4.7 trunk.
MMB paste is not different than any other paste operation. if it doesn't happen with ctrl+v, then it's likely not that. odd question: you don't happen to use a scroll mouse where the scroll wheel is also the middle button? i ask because the inputs your refer to scroll through their history when the wheel is spun, and it's often easy to do that when middle clicking ...
Aaron, I use a mousewhell mouse and yes middle mouse button is the wheel, but I am pretty sure that I have a feel whether for whether I drag the wheel or click it. And it never happened in Rekonq, while it happens in Konqueror and KRunner. And I did not see it in KDE 4.4. Well maybe, just maybe my wheel mouse got broken just as I upgraded KDE. I will replace it by another mouse just to make sure its no hardware defect and the mouse isn´t reporting wheel dragging additionally to mouse click. Thanks.
*** Bug 272037 has been marked as a duplicate of this bug. ***
(In reply to comment #15) > Aaron, I use a mousewhell mouse and yes middle mouse button is the wheel, but I > am pretty sure that I have a feel whether for whether I drag the wheel or click > it. And it never happened in Rekonq, while it happens in Konqueror and KRunner. > And I did not see it in KDE 4.4. Well maybe, just maybe my wheel mouse got > broken just as I upgraded KDE. I will replace it by another mouse just to make > sure its no hardware defect and the mouse isn´t reporting wheel dragging > additionally to mouse click. Thanks. Were you able to test this with a new mouse ? The only way I could replecate your problem is if I move the mouse wheel while pasting. Otherwise, I do not see the problem here at all.
Dawit, I did came around trying it until you asked again. And guess what this bug is totally, absolutely and enterely closed. Yes, it is the mouse. So no problem of KDE at all. I tried with three mouses. The one where it happens and two other all connected via USB. It happens with the one, but not with the other two under the same circumstances. So sorry for not thinking of a possible hardware problem earlier. Thanks Aaron for your hint which inspired me to try a different mouse.