Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1573577 - gitk doesn't copy to clipboard after upgrade to Fedora28
Summary: gitk doesn't copy to clipboard after upgrade to Fedora28
Alias: None
Product: Fedora
Classification: Fedora
Component: git
Version: 28
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Petr Stodulka
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2018-05-01 17:58 UTC by Paul DeStefano
Modified: 2018-12-10 00:02 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-12-10 00:02:08 UTC
Type: Bug

Attachments (Terms of Use)

Description Paul DeStefano 2018-05-01 17:58:01 UTC
Description of problem:
gitk seems to have stopped populating secondary clipboard with highlighted text, as normal.

Version-Release number of selected component (if applicable):

How reproducible:
Since Fedora28

Steps to Reproduce:
1. gitk
2. click on commit
3. try paste commands (primary or secondary are both wrong)

Actual results:
nither primary and secondary clipboards are populated when clicking on commit or highlighting text anywhere in gitk.

Expected results:
clicking on commit should populate the clipboard with commit hash.

Additional info:
Worked yesterday before upgrade.

Comment 1 Todd Zullinger 2018-05-01 20:30:10 UTC
Hmm, this seems to work for me.  I select a commit and then a middle-paste in the terminal pastes the commit id.

There aren't any changes to gitk which should affect this, so I would assume it's related to the desktop environment or tcl/tk.

Additional information on the environment needed to reproduce this might be helpful.

Comment 2 Paul DeStefano 2018-05-02 04:50:38 UTC
Oh, interesting.  I'm using Xfce DE.  What are you using?

Are you using Xwayland?

My middle button works from other applications, though.  It even seems to work on other Tcl/Tk applications I have.  So, there is something different with gitk compared to Tcl/Tk in general.  That's why I thought it might be application specific.

I also notice that primary and secondary seem to be the same, now.  If one is updated, so is the other with the same data, when it works.  When it doesn't work, neither is changed.  For example, seems like all GTK3 applications no longer update upon highlight, but CTRL-C copies to *both* clipboards.  Perhaps these are all related.

Thanks for your help.  Depending on your answers, perhaps this should go to Xfce maintainers?

Comment 3 Todd Zullinger 2018-05-02 21:51:53 UTC
I first tested with the default workstation install.  That's Gnome and Wayland.

Today I downloaded the F28 XFCE live image to test.  That uses lightdm and Xorg.  But it works for me there too, adding to the mystery. :)

I think I'm doing what you're describing.  When I open gitk it selects the commit id of the most recent commit.  If I tab back to a terminal and middle paste, the commit id is pasted.  If I select a different commit, that commit id is pasted.

I can also copy this to the clipboard (though it's a bit finicky for me, but I think that's just tcl/tk being unfamiliar).  For that, I have to click in the "SHA1 ID" field.  Then I have to double click to re-select the commit id.  Then Ctrl-C copies and back in a terminal, Ctrl-Shift-V pastes.

I'm not sure what to make of all that.  Do you happen to be able to test with Xorg?  That would give us a direct comparison.  If that fails for you too, then either it's something different about your install versus the live image I tested with or I'm doing something different than you are to get different results.

Comment 4 Paul DeStefano 2018-05-03 07:09:43 UTC
Todd, thank you so much for your help!  You are really going above and beyond.  The live image test was a good idea and I would have done it if you had asked.

I have a VM with F28 that I installed with only Xfce DE and it uses lightdm and Xorg.  I tested this in that env and I get the correct behavior there.

Yes, you are doing the right tests.  That's exactly what I'm doing.

So, on my main system, I use GDM and Xfce.  I think I need Wayland, or at least I want Wayland, for my GPU stuff (which has been broken for nearly 3 years now, but that's a different bug.)  In any case, I switched from LightDM back to GDM a while ago because of serious LDM problems I think are clearly fixed, now.

I say it's only gitk because I use true xterm, which has always had that auto-copyto-primary behavior.  That is still working on my system, so it seems like the core feature is not affected, generally.  But, it is broken in gitk.  Also, I use password gorilla, which is very unusual, but is actually a Tcl/Tk program, just like gitk, and that also continues to function as expected (i.e., when I highlight text, anywhere, it goes to primary and I can paste it with the middle button).

Let's just assume this is something with the three-way interaction of gitk, Xwayland, and Xfce.  I'm out of ideas, but you had a good one with the live image, so...got any more?

I could go back to LDM, but let's exclude that for now.

I could go to Gnome, but I also don't want to do that.

I could try Cinnamon.  I've been meaning to do that.

Is there a way to trace this in gitk?  Or in X11?  Did gitk get fully rebuilt for F28?

Comment 5 Pavel Cahyna 2018-05-03 09:28:48 UTC
(In reply to Paul DeStefano from comment #4)
> I could go back to LDM, but let's exclude that for now.

Why do you think the DM has anything to do with such issues? I would expect it to not have much influence on what is happening after you login (except maybe setting some environment variables and so).

Comment 6 Paul DeStefano 2018-05-04 09:11:51 UTC
I don't think DM is related, directly.  After troubleshooting those problems with LDM, I came away with the clear understanding that GDM <=> Wayland.  I'm pretty sure this is true, still, since I get Xwayland on my Xfce DE and the only thing I know I changed was DM.  (Now, I was using Xfce with GDM before LDM was the default for Xfce spin, so I manually switched to LDM to try to stay "normal", but I had to change back due to video problems that only GDM was handling correctly at the time.)  On the Xfce VM I installed from Live image, it uses LDM and does not start Xwayland.

Does that make sense?  I'm supposing it's Xwayland.

I don't think we have a good idea as to where the root cause of this issue could be located.  From my perspective, it's localized to gitk.  But, gitk seems to have this feature in Gnome and Xfce DE, but not my Xfce DE.  However, I'm not aware of any configuration options that could affect this.

What do you think it could be?

Comment 7 Todd Zullinger 2018-05-09 22:32:04 UTC
Hi Paul.  Sorry for the delayed reply, I was distracted for a few days.

As far as gitk and being rebuilt for f28, there isn't anything to build for gitk.  It's just script you can view in a text editor. :)

And while git as a whole was updated from 2.14.3 in f27 to 2.17.0 in f28, there were no changes to gitk in that period.  (This says a lot about how little development effort goes into gitk these days.  The last change to gitk was in git-2.12.0, released in February 2017.  The changes are in this commit: https://git.kernel.org/pub/scm/git/git.git/commit/?id=ffac48d093d.)

I'm not sure what the cause might be at this point.  AFAICT, Xfce doesn't support Wayland, so that should have nothing to do with this.  You mentioned using GDM as the login manager, which does install a number of Gnome libraries (and would run Xwayland itself, but when you login to Xfce you'd be running Xorg -- again, as far as I know).  I don't know whether any of those Gnome libraries could/would affect Xfce's clipboard or gitk.  I guess it's possible, but I'm grasping there.  Ideally we need to narrow down a method to reliably reproduce this, then we can hopefully determine what's different.

I'll try to install GDM on the Fedora 28 Xfce test instance I have and see if that affects anything.

I'm not well-versed in how to debug a tcl/tk app like this.  My poor-man's debugging tactic would be to sprinkle some print statements into the code to see that the expected copying is being run.  Another thing to try would be to find a basic tcl/tk demo app with copy/paste and see that it works.  If it does, comparing what it does to gitk might turn up something.  Since gitk is not very actively maintained these days, it's possible that it's using some ancient method that needs to be updated.  (But I'm not sure that tcl/tk itself changes enough for that to happen, to be honest.)

Comment 8 Paul DeStefano 2018-05-10 04:26:42 UTC
Yeah, I wish I knew more about it, myself.  I don't understand how two root windows could operate on the same head.  But, I have heard something similar before, so I think you are right.

Good point about gitk.  I guess I should have asked about tclsh begin rebuilt.  tclsh isn't linked to anything interesting, but I guess it would be the tk modules that are at issue.  Those probably were rebuilt, if not updated, too.

I actually just wrote a Tcl/Tk program in Python (tkinter).  I could probably whip up a single window with text pretty quick.  As I say, both this program I wrote and another very old tcl/tk program I regularly use show no noticeable change in highlight-to-primary behavior.

Aha!  Here's another one: git gui.  That's also a tcl/tk program (right?) and it also no longer copies to primary.

Hmm, okay, here's something.  It's very easy to create a program that should work.

$ tclsh
% package require Tk
% text .t
% pack .t

Now, you can type text into the text box.  And, if you highlight it, it should go to the primary.
Oh, now check this out.  When I check the primary with "xclip -out -selection -primary" it says the right thing is in primary!  Aha!  That's very interesting.  Seems like gitk is doing what I want.  It's getting the data *back out* of primary that has changed.

Well, uh, I think it might be my mistake all along.  Very very sorry.  I think it wasn't the copy side that changed, but the paste side.  Or something else.  OMG, so sorry.  I appreciate your help and time.  Best help I ever got on RH bugzilla.  Sorry I didn't come to more.

Note You need to log in before you can comment on or make changes to this bug.