New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 754193 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Chrome quereies X Primary clipboard twice

Reported by cgogoli...@gmail.com, Aug 10 2017

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36

Steps to reproduce the problem:
1. Put "foo" into the primary X clipboard and display when it is queried by running

$ echo "foo" | xclip -verbose

in a terminal.
2. Past via middle click into any text box in a website displayed in Google Chrome
3. The output of the above command is

Connected to X server.
Using UTF8_STRING.
Waiting for selection requests, Control-C to quit
  Waiting for selection request number 1
  Waiting for selection request number 2
  Waiting for selection request number 3

indicating that Chrome queries the X primary clipboard twice.

What is the expected behavior?
With previous versions of Chrome queried the X clipboard only once, resulting in the output 

Connected to X server.
Using UTF8_STRING.
Waiting for selection requests, Control-C to quit
  Waiting for selection request number 1
  Waiting for selection request number 2

What went wrong?
Apparently Chrome is querying the X primary selection twice.

This annoyingly breaks third party password manages such as pwsafe that copy the username to the X clipboard, wait until it was pasted, then copy the password to the clipboard, wait until it was pasted, and then exit. When such a password manager is used with the new version of chrome, after middle clicking into the "username" text field on a website, Chrome discards the username and instead puts the password in the username box. 

Did this work before? Yes I think the problem was introduced with the update google-chrome-stable:amd64 59.0.3071.115-1 -> 60.0.3112.90-1

Chrome version: 60.0.3112.90  Channel: stable
OS Version: Debian
Flash Version:
 
Cc: susanjuniab@chromium.org
Labels: Needs-Triage-M60 Needs-Feedback
cgogolin85@ Thanks for the issue.

Unable to repro the issue on Ubuntu 14.04 using latest canary 62.0.3200.0, latest stable 60.0.3112.113 and on the reported version 59.0.3071.115 with the below steps

1. launched Chrome and opened terminal.
2. Run the command $ echo "foo" | xclip -verbose in the terminal.
3. Selected a word on Chrome and could see the message "Waiting for selection requests, Control-C to quit
  Waiting for selection request number 1" only once on the terminal.

Please find the attached screen shot and confirm if anything is missing.
Also request you to retry the issue and  please provide us the screen cast if the issue still exists.

Thanks..
754193.png
117 KB View Download
Status: WontFix (was: Unconfirmed)
Re-tried the issue again on the latest Canary 63.0.3236.0 and Stable 61.0.3163.100 and unable to reproduce the issue.
Closing this issue as there is no update from the reporter for more than a month.

Please feel free to file a new issue if there are any issues on the latest chrome versions.

Thanks..
Well, you didn't really go through my steps to reproduce the problem. If you read carefully, you are not supposed to "Selected a word on Chrome" (which will put this word into the clipboard and this works just fine) but "Past via middle click into any text box in a website displayed in Google Chrome". The latter queries the x clipboard twice (which it shouldn't) as is proved by the appearance of three "Waiting for selection request number X" lines in the output.
I don't have canary installed, but in Version 61.0.3163.100 (Official Build) (64-bit) the problem is still present. 

Sign in to add a comment