This continues to hit me many times a day.  
I can't paste data into chrome windows reliably.  Maybe half the time,
I have to paste the text into an xterm, then select it again, and 
then paste it into chrome.  It's driving me nuts.

Another example of bizarre behaviour:
I wanted to copy a link from a bookmark into a mail message, so:
 - right-click on bookmark in bookmark toolbar to bring up menu
 - click on "Edit..."
 - triple-click on text in "URL" field.  Text is highlighted, so 
   presumably selected.
 - (optional) paste the text into an xterm----works
 - attempt to paste text (via middle-click) into type-in box in chrome
   (nothing happens  (this is the same result as firefox, both firefox
   and chrome use windows-style "modal" pop-ups, even on X11)
 - close the bookmark "edit" window via its "cancel" button
 - again attempt to paste text 
   (again, nothing happens  (on firefox this works))
 - (optional)
   attempt to paste the text into an xterm, and _this_time_ nothing happens.
   Chrome has apparently _deleted_ the clipboard entry just because the text 
   is no longer visible!   (Compare with xterm, where you can select text from it,
   kill the xterm, and then paste the text into another window.)

I've run into similar problems.  I've found three related bugs:

1) If you use middle-click to paste, pasting again will paste text from after the place you first pasted instead of pasting what's in the PRIMARY selection.  The original text is also de-highlighted.

2) If you have a search open in a tab, go away and copy something, then open that tab again, it replaces the PRIMARY selection with the search term.

3) If you use middle-click to paste, it pastes at the insertion point, not where the button was clicked.  This is very annoying because it is easy to forget and it requires using the keyboard in between copy and paste actions.

The first was really easy to reproduce so I opened bug 80146

I haven't bothered to file bugs on the others because I see dozens of copy-paste related bugs open already.

Re comment 2, point 2 is bug 79597.  Vote if it bugs you!

I hate this. Why is Chrome overriding default behavior when users are used to, and like, the default. I too swear at Chrome multiple times per day.

Another way to reproduce the original problem is to open a terminal window and highlight some text. In Chrome, start composing an email. After 5-6 characters, the highlight in the terminal window will disappear. This does not happen in Firefox, and I have trouble reproducing it on other webpages, but it happens very consistently in Gmail.

Chrome 15.0.874.102 beta

Removing milestone for all Unconfirmed M17 bugs.

Hi chromium devs!

I would like to pay your attention to this bug.

Since some time (I guess this started around 7th or 8th version) chromium started to damage text that is copied or test that is inserted.

I do not know how to explain this but I have a video that demonstrates this

http://dl.dropbox.com/u/21475911/7.ogv

I thought its an issue of my clipboard manager and filled a bug for it (http://sourceforge.net/tracker/?func=detail&aid=3301614&group_id=235597&atid=1097277) but after some digging I found that its the issue of chromium. With FF all is OK.

Also I had an idea to use another clipboard manager but any of clipit, xclip and xfce-clip plugin did not help    

I made a search in you BTS and found next bugs that saying about same: Bug 90681, Bug 100870, Bug 65087, Bug 82603

There are dozen of bugs that have similar subject but reporters do not provide nice STR.

Sometimes I think exactly like author of comment #4

Could you please take a look on this and make your best efforts to fix this till next release

Thanks

This bug has become a dumping ground for all Linux pasting issues it seems. It makes it really hard for developers to track what's been fixed and what's still broken. Please keep discussion on each bug focused.

Comment #2:
Bug 80146 doesn't seem to occur on recent versions of Chrome.
Bug 81392 is in progress, but has some issues I'm still working out.
I've filed bug 114838 about inserting at the cursor rather than the caret.

Comment #8 is probably 100870, but I don't have enough information to be sure. Please post any follow ups there.

Let me describe again the symptoms that caused me to file this bug originally.

Right now, as I type, I have something selected in an xterm.
    a) I can paste it into another xterm.
    b) I can paste it into chrome's address bar.
    c) I cannot paste it into the chrome edit window in which I'm
        composing this message using gmail.
I notice this effect dozens of times day; I can reproduce it at will
using the procedure I gave originally.  I can reproduce it only with chrome.
Symptoms (b) and (c) taken together suggest an inconsistency
in chrome, which in turn suggests that there are (at least) two different places
in chrome that are handling X selections, and the two are being
handled differently.
I do not remember seeing an occasion where the selection handling was
wrong in the address bar.

So one strategy for adderssing the issue is to find places where selections are
handled, and make them use the X calls in a uniform style-----copy
what's done for the address bar,
since it seems to work significantly better than other input text areas.

Do I need to be using x2x? A simple test with rxvt-unicode/xterm and the Gmail compose window works fine for me...

Also, please include your Chrome version from chrome://version. I've made some fixes in this area but I'm not sure if your version has them.

Version output is below.

Using x2x is a very simple way to do it---it happens every time if you
select something on one screen,
and use middle-button to paste into chrome on another screen
(connected via x2x).
I see oddities in other ways, but it's much more hit-and-miss and I
can't find a simple way to reproduce.

Of course, x2x might be doing something unusual, but that still can't
explain why the chrome address bar would
behave differently from other type in boxes in the same chrome window.


Google Chrome	17.0.963.38 (Official Build 118053) beta
OS	Linux
WebKit	535.11 (@105210)
JavaScript	V8 3.7.12.17
Flash	11.1 r102
User Agent	Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.11 (KHTML,
like Gecko) Chrome/17.0.963.38 Safari/535.11
Command Line	 /usr/bin/google-chrome
--proxy-pac-url=http://cache.corp.google.com/loasproxy.pac
--flag-switches-begin --enable-print-preview --flag-switches-end
Executable Path	/opt/google/chrome/google-chrome
Profile Path	/home/m3b/.config/google-chrome/Default

My version is 18.0.1025.151 running on Ubuntu 11.10.

My symptom is that when copying from Keepass2 I can paste to the address bar in Chrome but not the form fields on the web page.

Yes, you must be running x2x.

My workaround is to paste my other-machine-copied text into a local-machine terminal, then re-copy it and paste it into the local-machine chromium.

It happens only with chromium/Chrome and only when using x2x.  It happens about 1/10th of the time.

The Keepass2 bug is http://crbug.com/115446. This bug is specifically about x2x.

@dcheng, @chadmill: Thanks.

Am also seeing this on Ubuntu 12.04 with 18.0.1025.162.   Can paste from KeePass2 into anything on Ubuntu except an HTML text input inside Chrome.  Please fix ASAP!  Thanks.

Regarding comment #17 - the bug http://crbug.com/115446 cannot fix the KeePass2 problem as it is about Java and KeePass2 is written in C# on top of Mono.

Not seeing this issue anymore with version 19.0.1084.46 on top of Ubuntu 12.04.

I'd mark this as closed.

I'm using keepass2 in linux and i can't paste the password to the web page, but i can past it to the adrress bar. 

Due to the age of the issue, changing the priority to P3, however because it has at least 10 stars, marking it for review.

This bug still exists.

Version 31.0.1650.63 Ubuntu 13.10 (31.0.1650.63-0ubuntu0.13.10.1~20131204.1)

I have just started experiencing this problem after moving from Kubuntu 13.10 to Kubuntu 14.04 LTS.

Can it be related to a configuration file problem or something collateral rather than central? My Chromium on 13.10 works perfectly! Alas not on the new LTS distro.

Interestingly, when I downloaded Google Chrome Version 34.0.1847.116 for AMD64 and tried it out, the problem disappeared. I hope that helps in ferreting out the cause in Chromium. Could it be integration with KParts or something like that?

The Chromium version is Version 34.0.1847.116 Ubuntu 14.04 aura (260972).

#27, #28,
Somehow Ubuntu's Chromium 34 package has been shipped with some experimental/immature features enabled (Aura, HiDPI, ...). These features are not yet enabled in official Google Chrome stable releases for Linux. You cannot simply expect that Ubuntu's Chromium 34 is nearly equivalent to Google Chrome 34.

This problem still exists after v34. Now I am testing 36. When trying to paste with middle mouse button from Gnome Terminal into Chromium, the effect is that nothing happens - expected the text to be pasted into Chromium. This can be reproduced on both Chromium's address bar and a <textarea> like the one I am writing into. Tested Chromium is Version 36.0.1985.125 Ubuntu 14.04 (283153). Please let me know if you can reproduce this on a non-Ubuntu Linux.

I can also confirm this issue for www-client/chromium-39.0.2171.65 on gentoo linux. Really annoying issue and preventing me from switching from firefox...

With Chromium 44.0.2403.155 on Arch Linux, I still experience this issue.

With Chromium 45.0.2454.101 on Ubuntu 15.04, I still experience this issue.

I'm on Fedora 22, Chrome 45.0.2454.85 

I always assumed my copy/paste problems were a security "feature".  If I copy text from somewhere by highlighting it (the standard unix way), it won't paste into most chrome forms (text boxes, input fields etc..).  I can however copy into gmail.  So, I've been taking stuff from other apps, copying into a gmail, then I ctrl+C it from the email and Ctrl-V it into wherever I'm trying to paste it.  I had always assumed google didn't want to mess with the system copy/paste buffer out of concern for security.  As an example of a similar security decision, Chrome won't let you use external programs as text editors, for example, but Firefox will.  This is explicitly explained as a security concern (do you want your browser to be able to launch external programs?).

Does anyone know if this is the case?  Does this make sense to anyone?

Thanks

pasting X selection is by default turned off on Ubuntu, so anyone intentionally enabled it, well, has the intention. Besides, on my Ubuntu the behaviour is inconsistant: usually (80% of the time) I can paste into any form on chromium, and on 20% of the times, not even into gmail. Don't know what's the trigger, but the 1st paste since boot usually work.