Password copying

[franko108]

Hi,
I hope this project is still alive?

I have some issue copying password or username from Gorilla.
It is set to copy password on double click. However, I have to do it twice, two times double click, and then the password is copied.
Right click -> copy username or copy password, also has to be done twice to be actually copied.
A bit strange.

I'm using it on Ubuntu 19.10, and on the 2 desktop machines, the same behavior.
Gorilla version: 1.6.0.beta 1

[SavSanta]

It may take a while to get a response from the main dev. Though out of curiousity. I ttied this on two different Linux Mint installations with 1.60 Beta 1. There was no issues.

Try looking into some system settings on Ubuntu such as the rate of the clicks needed or if it's somehow delaying clicks. You can maybe use the tool xev to look at Button press/release events as well.

Also another thing i just thought of is make sure you dont have an additional system cliptray running that is intercepting the first copy sequence?

[rich123]

This is important:

Also another thing i just thought of is make sure you don't have an additional system cliptray running that is intercepting the first copy sequence?

The most common cause of issues like this has been systems starting clipboard managers by default in the background. Lots more details can be found in at least issues #41, #83, #108, #113 and #111.

With that said, do you have "Use Gorilla auto-copy" turned on in the General tab of the preferences pane? If yes, try turning it off and see if that helps. If turning it off helps, then turn it back on and try adjusting the "Latency" value up or down to see if a different latency value helps.

[franko108]

Hi,
thanks for reply, I don't think I have other clipboard managers active on the system.
However, I'm currently within Virtual Box, and here is some active processes:
/usr/bin/VBoxClient --clipboard
I've killed the process, restart Gorilla, the same behavior.
I'll check what is on the native Ubuntu installation.

"Use Gorilla auto-copy" is turned off.
Here are my General settings:

[rich123]

Hmm, it is possible that the cause here could be something with VirtualBox. Do you have VB's "clipboard integration" turned on?

It could also be that VBox adds just enough latency that sometimes a double click is seen as two sequential single clicks by the time the events go from host os -> Virtual box -> virtual os -> X -> running gorilla process.

Double clicks are detected (and this is true of every OS, on every platform, everywhere) by detecting two left clicks within a short time of each other (this is because all the mouse hardware reports is "click occurred"). Anything that adds additional latency in the processing of the "click occurred" events, if the two events are near the maximum length of time used, could result in the two events appearing to be "too far apart".

The detection of double clicks on rows in the table is done using Tk's built in native method (i.e., not by any special code in Gorilla). So if the actual detection is being missed, that points to the possibility of some extra latency somewhere in the code outside of PWGorilla and Tcl/Tk itself. And if that is where the issue is happening (somewhere between host OS, VBox, and guest OS) there is not going to be anything I can do code wise in Gorilla to actually work around the issue.

Do you have any way to check on Linux running natively (i.e., without VirtualBox in the middle) to see if you also see the same issue?

Since you have Linux in the VM, you should have a native Tcl/Tk interpreter installed (if not, you can use the package manager to install it). You can use this little snippet of code to test with:

----cut---cut---cut---
#!/usr/bin/wish

set tv [ttk::treeview .tv]
pack $tv
$tv insert {} 0 -text "Click Me"
bind $tv {puts "Double Click Detected at [clock format [clock seconds]]"}
---cut---cut---cut---

Copy everything inside the ---cut--- lines (but not the ---cut--- lines themselves) to a file with a name of your choosing.

Then open a terminal (xterm, rxvt, gnome terminal, etc.) and change directory to wherever the file is stored. Then launch the file like so (assuming you named it 'test.tcl':

wish test.tcl

That will launch a minimal version of how Gorilla detects double clicks on rows in the view. You want to launch from a terminal because when this bit of code detects a double click, it prints a line to the terminal saying it detected one, so you want to see that output. Then try double clicking the "click me" line in various ways to see if you have the same result as you see with Gorilla. If you do see the same result (sometimes double clicks get lost) then that result means that whatever is happening is actually outside of the ability for the PWGorilla code to do anything about the issue.

[franko108]

Hello,
thank you for your reply.

I'm currently on the native Ubuntu 19.10 machine, not within Virtual Box.
Here I can't find any other active clipboard program (unless I'm not aware of).

I've tried your test with script, window with text "Click me" do appear, but when I double click it (or any number of times or combinations) no returning message in a shell.

Installed Tcl version is 8.6.9+1
Gnome version is 3.34.2

Here is the screenshot:

I can try to find some log file if this might help? Not sure where to look, syslog is returning a little:

$ sudo grep gorill /var/log/syslog
Apr 29 21:20:55 ubb19 systemd[1794]: gnome-launched-password-gorilla.desktop-5942.scope: Succeeded.

[EDIT] - Here is "Use Gorilla auto-copy" disabled as well.

[rich123]

There was a report of a copy-paste issue (but I'm unable to locate the specific issue, github's 'search' being as inadequate as it is) some time ago that indicated that in newer Gnome's that the Gnome file manager program was also performing clipboard management duties behind the scenes. Note, I do not know why a 'file manager' had clipboard management duties added to it, nor did I go try to find out why, since I'm not a Gnome user myself.

But it is interesting that you see no output with the test program in the terminal window where you launched the script.

If you want to try another test, add this line to the end of the test script:

bind $tv {puts "Single Click Detected at [clock format [clock seconds]]"}

and then retry the test. That line will add a binding to "single click" along with the existing double click binding. You should, at least, see single clicks being reported in the shell from where the script was started when clicking on the "click me" text. Note that if a double click does register, you'll first see it reported as a single, then see a report for a double.

If you also see nothing, then that partially explains what is going wrong, something is blocking/preventing Tk from receiving mouse events in many cases. I have no idea what might be causing this, but if you don't see anything from clicking on the "click me" text, or only occasionally see a click reported, then this does mean the problem is occurring somewhere before any of the PWGorilla code. It just happens that PWGorilla revealed the issue, but is not the cause.

[franko108]

Hi,
if I add the line in the previous test script:
bind $tv {puts "Single Click Detected at [clock format [clock seconds]]"}
nothing really changes, single or double click, no response in shell.

BTW, I just upgraded on Ubuntu 20.04, but no difference.
Gnome version 3.36.1
Tcl 8.6.9

Very possible that something interferes before gorilla as you said, I don't have idea what it could be.

Best,

[rich123]

Argh. Github is swallowing the angle brackets (probably an improper attempt at preventing a cross-site scripting attack). I noticed now when you replied with the line you added, and the button to bind is missing. I'm going to try attaching the file instead (and hopefully github does not change the file contents).

test.txt

Sorry for the confusion, but because github altered what I pasted in (after submitting the comment at that) and I didn't look closely enough after submitting, the result was the test script would never have output anything. Note also that the file is named *.txt because github would not let me upload it with a name *.tcl.

[franko108]

Hi,
thanks, this script is working. I get response for each single click and for double click:

$ wish tc2.sh 
Single Click Detected at Sat May 02 22:07:27 CEST 2020
Single Click Detected at Sat May 02 22:07:29 CEST 2020
Double Click Detected at Sat May 02 22:07:30 CEST 2020

BTW, I think that markdown shall allow you to put real code within a triple back tick, or choosing "code" from the menu:

#!/usr/bin/wish

set tv [ttk::treeview .tv]
pack $tv
$tv insert {} 0 -text "Click Me"
bind $tv <Double-Button-1> {puts "Double Click Detected at [clock format [clock seconds]]"}
bind $tv <Button-1> {puts "Single Click Detected at [clock format [clock seconds]]"}

[rich123]

Ok, that indicates that the single and double clicks are making their way into Tk normally. It does not yet explain the issue with copy on a double click.

Explicitly marking code blocks preserves the special characters, so that's good to know.

Next, the bottom line of the main gorilla window where the list of entries is shown is a status bar. When you have the instances of double click being missed, so you also see nothing in the status bar as well? Normally when a password or a login id is copied to the clipboard a message appears in this bar for a brief period of time indicating what happened. I'm presuming that when double click is missed, no message appears, but if you do see the message, but nothing pastes, then that indicates something else weird.

Also, any chance your system is running Wayland?

[franko108]

Additional pattern, when I copy password the first time after opening the program, it is copied regularly.
On the next copy password from Gorilla, in the clipboard is still the first password. After next double click, (or two times double click), the new, proper password is being copied.

Yes, every time doing the double click, there is a message on the bottom of Gorilla window "Copied password to clipboard" (or username if I choose right click and copy username)

Wayland is not installed.

[rich123]

What happens if after you first open PWGorilla, you copy a password, paste to somewhere to verify it copied, then exit PWgorilla and then try pasting again after exiting PWGorilla?

Also, what happens if after you first open PWGorilla, you do a copy, but do not yet paste, then exit PWGorilla then try to do several pastes?

Before both of the "first open" steps above, try pasting to verify that there is nothing, or something other than what you expect to see from PWGorilla being pasted. If need be, copy and paste something else from somewhere else first to make sure the clipboard starts out "clean" (as in nothing from PWGorilla in the clipboard).

Also, which method are you using to paste: middle mouse button or keyboard/paste menu selection?

[rich123]

Also, can you download a source bundle from Github for use for further testing? Go to the main Github page for PWGorilla (https://github.com/zdia/gorilla/tree/pre160), change the "Branch" drop-down button to say "pre160" (it will default to 'master') then click the green "clone or download" button. A menu will appear and at the bottom will be "download zip". Click "download zip" to download a zip file containing the Gorilla source.

Then unpack the zip somewhere, the where really does not matter. Next, open the gorilla-pre160/sources/gorilla.tcl file from where you unpacked the zip in a text editor (joe, jed, nano, vi, emacs, etc.) and search for this line:

set item [ GetSelected$activeSelection ]

It should appear in a block of code that looks like this:

variable activeSelection

                ArrangeIdleTimeout

                set item [ GetSelected$activeSelection ]
                if { $what eq "" } {
                        set what $activeSelection
                }

Insert this line just after the "set item" line:

puts stderr "Copied '$item' to clipboard"

Then, about 77 lines farther down in the file this line will appear:

return [string range $data $offset [expr {$offset+$maxChars-1}]]

Immediately before that line, add this line:

puts stderr "Returning '[string range $data $offset [expr {$offset+$maxChars-1}]]' as contents for '$activeSelection'"

Then save the file, and try testing copy/paste with this version of the file by launching it from a Bash terminal so you can see the output lines printed to the terminal.

You should see the "Copied '????' to clipboard" line output each time PWGorilla copies something to the clipobard, and the ???? will be replaced with the data that should have gone into the clipboard. You can compare this to what you actually get from a paste to see if what is being pasted matches what PWGorilla attempted to copy.

You should also see the "Returning '????' for '????'" line any time you actually do a paste, and it should show the same contents as the "Copied" line (unless you select a different entry) and it should also match what you get for a paste.

Do some more testing with pasting after a new launch and pasting after a paste, i.e., all the situations that seem to create the problem, and compare what the test copy is stating it places into the clipboard with what actually pastes elsewhere. If anything does not match up, then report back what did not match (obviously clear the actual password content values before reporting).

[zaphod80013]

Don't have details to hand but I've been seeing similar issues on Pop OS 20.04 & MacOS Mojave; I need to verify which versions I'm running in each environment. On OSX it's been going on for a while but I'm not using the Mac that much so its not it's not been a big problem for me. But now i'm in the middle of installing 20.04 & changing email providers so I'm seeing it much for frequently. Both environments are native, no vm's involved.

Let me know if there's a diagnostic I can usefully run to help troubleshoot.

[rich123]

@zaphod80013 if you can run the source files on either platform, then trying the edits I suggested in my prior response and launching from a terminal so you can see the output from the puts statements might help diagnose what is going on. Obviously remove any actual password data values (as those puts will output them to the terminal for you to see) before posting anything back here to github.

[franko108]

Hi there,
I entered your code in sources/gorilla.tcl.

Now, every double click in Gorilla, shell gives output as:
Copied 'mypassword' to clipboard
(real password instead a text above). And I can't paste it anywhere.

But only when I do 4 times click (twice double click) I get:

Copied 'mypassword' to clipboard
Copied 'mypassword' to clipboard
Returning 'mypassword' as contents for 'Password'

And then I can actually paste the mypassword from clipboard.
So, behavior is the same, two times double click to get password actually copied in a clipboard.

If I can do more debug, let me know.

Previous question, I'm using double click to copy password from Gorilla. Paste with ctr+v, but the same is with mouse right click and paste.

[EDIT]
I see, on double click in Gorilla, password is copied on middle mouse button. Every time is like that, I can paste it with click of middle mouse button. This is how it works on my environment.

[rich123]

First, a clarifying question as I am slightly uncertain as to your exact meaning:

I see, on double click in Gorilla, password is copied on middle mouse button. Every time is like that,

Here you mean that the middle mouse button paste operation always works? If yes then that is helpful, because it means whatever is going on is related to the X11 CLIPBOARD selection and does not effect the X11 PRIMARY selection.

If I can do more debug, let me know.

Actually, there are a few additional mods you can make that may help track down what is going on. Below I'm going to paste output from git diff. There are two ways you can apply this, 1) manually, 2) automatically.

If you have the "patch" utility installed, you can start from an unmodified copy of gorilla.tcl from the tip of the pre160 branch (i.e., what should be in the zip file you downloaded last time). You can copy out the patch data below to a file (lets say you call it "p"). Then, you place the file "p" in the same directory with an unmodified (from the pre160 branch) "gorilla.tcl" and type this at the bash command line:

patch < p

Which should give you this output:

$ patch < gd 
patching file gorilla.tcl
Hunk #1 succeeded at 6990 (offset 1 line).
Hunk #2 succeeded at 7054 (offset 1 line).
Hunk #3 succeeded at 7082 (offset 1 line).
Hunk #4 succeeded at 7134 (offset 1 line).

The manual method will require you to go through this patch file and find the appropriate locations to change, and make the changes (much like you did last time). Here's how to interpret the output:

Lines that begin with a space are 'context' (i.e., they allow you to find the right place to edit). Lines that begin with a minus character (-) are removed (or changed, as diff shows a change as a removal of the old and insertion of a new item). Lines that begin with a plus character (+) are added. Lines that start "diff", "---", "+++", or "@@" are metadata from git for the 'patch' program purposes, you can ignore them if you are making hand edits. Note that this below contains some of the changes you've already made, be sure to leave those in place. But in one spot, I made a subsequent edit to an already suggested debug edit, so do make a careful comparison if you choose to manually apply the patch by hand.

diff --git a/sources/gorilla.tcl b/sources/gorilla.tcl
index 149c769..a55476d 100755
--- a/sources/gorilla.tcl
+++ b/sources/gorilla.tcl
@@ -6989,18 +6989,18 @@ namespace eval gorilla::CopyToClipboard {
 	# used to support "STRING" copy type for X11 clipboard callbacks
 	variable activeSelectionData ""
 
 	#
 	# Handler for the X Selection
 	#
 
 	if { [ tk windowingsystem ] eq "x11" } {
-		selection handle -selection PRIMARY   . [ namespace code XSelectionHandler ]
-		selection handle -selection CLIPBOARD . [ namespace code XSelectionHandler ]
+		selection handle -selection PRIMARY   . [list [ namespace code XSelectionHandler ] PRIMARY]
+		selection handle -selection CLIPBOARD . [list [ namespace code XSelectionHandler ] CLIPBOARD]
 	}
 
 	# -------------- #
 	# public methods #
 	# -------------- #
 
 	proc Username { {mult 1} } {
 		variable activeSelection Username
@@ -7053,16 +7053,17 @@ namespace eval gorilla::CopyToClipboard {
 		#
 		# Consolidates all of the copy to clipboard management code into a single
 		# proc.
 		variable activeSelection
 
 		ArrangeIdleTimeout
 
 		set item [ GetSelected$activeSelection ]
+		puts stderr "Copied '$item' to clipboard"
 		if { $what eq "" } {
 			set what $activeSelection
 		}
 
 		if { $item == "" } {
 			set ::gorilla::status [ mc "Can not copy %s to clipboard: no %s defined." [ mc $what ] [ mc $what ] ]
 		} else {
 			switch -exact -- [ tk windowingsystem ] {
@@ -7080,36 +7081,41 @@ namespace eval gorilla::CopyToClipboard {
 
 					# performing a clipboard clear/append cycle under X11 is likely
 					# superflorious - if so it will do no harm
 					clipboard clear
 					clipboard append -- [ GetSelected$activeSelection ]
 
 					foreach sel { PRIMARY CLIPBOARD } {
 						selection clear -selection $sel
-						selection own   -selection $sel .
+						puts stderr "Claiming ownership of selection '$sel'"
+						selection own   -selection $sel -command [list [namespace code lost] $sel] .
 					} ; # end foreach sel
 
 				}
 			}
 
 			variable copy_start_time [clock milliseconds]
 			ArrangeToClearClipboard $mult
 			set ::gorilla::status [ mc "Copied %s to clipboard." [ mc $what ] ]
 
 		} ; # end if item == ""
 
 	} ; # end proc finish
 
+	proc lost {what} {
+	  puts stderr "Lost ownership of selection '$what'"
+	}
+
 	# ----------------------------------------------------------------------
 	# X Selection Handler
 	# ----------------------------------------------------------------------
 	#
 
-	proc XSelectionHandler {offset maxChars} {
+	proc XSelectionHandler {what offset maxChars} {
 		variable activeSelection
 		variable activeSelectionData
 		variable copy_start_time
 
 		switch -exact -- $activeSelection {
 			None {
 				set data ""
 			}
@@ -7128,17 +7134,17 @@ namespace eval gorilla::CopyToClipboard {
 			}
 			String {
 				set data $activeSelectionData
 			}
 			default {
 				set data ""
 			}
 		}
-
+		puts stderr "Returning '[string range $data $offset [expr {$offset+$maxChars-1}]]' as contents of '$activeSelection' for X11 selection $what"
 		return [string range $data $offset [expr {$offset+$maxChars-1}]]
 	}
 
 	# --------------------------------------------------------------------
 
 	proc GetSelectedURL {} {
 		if { [ catch { set rn [ gorilla::GetSelectedRecord ] } ] } {
 			return

Then give this version a try again in the same way as before, recording what PWGorilla outputs to the terminal window. The big change here is to output an indication of PWGorilla loosing ownership of the X11 CLIPBOARD selection. I have a suspicion you may see something like this below when the issue occurs:

Copied '....' to clipboard
Lost ownership of selection 'CLIPBOARD'
Copied '....' to clipboard
Returning '....' as contents of 'Password' for X11 selection CLIPBOARD

Now, for a tiny bit of both good and bad news. I've had your issue occur here, exactly once, and sadly before I made the additional debug tweaks to output the "Lost ownership" line above. And so far I have not been able to find any way to reproduce the glitch a second time. which is most irritating, because if I could reproduce it here reliably, that would help significantly with tracing down the problem.

[franko108]

Hi,

Here you mean that the middle mouse button paste operation always works? If yes then that is helpful, because it means whatever is going on is related to the X11 CLIPBOARD selection and does not effect the X11 PRIMARY selection.

Yes, that's correct, password is copied to the mouse middle button function.

Sorry, I didn't understand your instructions. I do have a patch utility.
There is already a shell script p file in sources/p.
If I run:

~/tmp/gorilla2/sources$ patch < p
patch: **** Only garbage was found in the patch input.

Or you want me to copy something else to so called p file and then run: patch < p

[rich123]

Copy the portion from the prior issue item beginning with "diff --git" and ending with " return" into a file (I just called it p, you can call it whatever you want). Then, starting from an unmodified copy of gorilla.tcl (i.e., unzip the zip you downloaded from github again) use patch to apply the file that originated from the copy action above to gorilla.tcl. If you name the copy/paste file something other than "p" then substitute the other name for "p" in the "patch < p" command line statement. Whatever you do name the file, it needs to be placed in the sources/ directory where gorilla.tcl exists. The best order is 1) unzip an unmodified gorilla.tcl; 2) copy/paste the portion from the prior issue into a file in sources/ directory; 3) run "patch < p" [substituting the filename you used for "p"] the same way you did above.

[franko108]

Ok, I did that, here are the results from the shell:

• After first double click, (copied password from Gorilla):

Copied 'my_passwd' to clipboard
Lost ownership of selection 'PRIMARY'
Claiming ownership of selection 'PRIMARY'
Claiming ownership of selection 'CLIPBOARD'
Returning 'my_passwd' as contents of 'Password' for X11 selection CLIPBOARD
Returning 'my_passwd' as contents of 'Password' for X11 selection CLIPBOARD

(password can't be pasted at this point, only with middle mouse click).

• Next double click:

Copied 'my_passwd' to clipboard
Lost ownership of selection 'CLIPBOARD'
Lost ownership of selection 'PRIMARY'

Now is password copied to clipboard and can be pasted with CTRL+v

[rich123]

That second experience indicates that something else is messing with the clipboard protocol. Those two "lost ownership" entries means that PWGorilla is not supplying data for a clipboard paste. So the fact that you can paste, after PWGorilla lost ownership of both, means that some other program is what is returning the password data that PWGorilla originally did copy to the clipboard.

The way the X11 clipboard protocol works is that at most one program has "ownership" of the CLIPBOARD selection, and when another program performs a paste, that other program asks the current selection owner to send over the contents of the clipboard.

Those two "lost ownership" lines, without two "claiming ownership" lines to match, mean that after the second double click, PWGorilla was not the program that had ownership of the CLIPBOARD selection, so the fact that a paste works means some other program is the owner. Note also that you quoted no "Returning 'my_password' as contents" lines for the second paste. That line is output by the code edits anytime another program asks for the clipboard contents and PWGorilla is the owner of the selection and is returning the data. Without those lines appearing, the clipboard contents that were pasted did not come from PWGorilla, they came from something else.

There was a report some time back about the gnome file manager performing "clipboard manager" tasks (why a file manager was modified to also be a 'clipboard' manager I do not know). If you do have gnome file manager running, try closing all of its windows, and if it keeps a copy of itself running in the background, try killing off that copy, and see if doing so makes any difference.