As of 0.11 r4998 the osx clipboard works as expected, by r5144 however, copying client-side does not register any change at all with clipboard
, primary
, or secondary
, as indicated by the output of the gtk_clipboard_tool... and obviously will not paste into the xpra session apps at all.
Testing was all done with 0.11 r5257 fedora 19 server.
Please bisect it, only 146 revisions should not take more than 7 steps.
Also, XPRA_CLIPBOARD_DEBUG=1
may shed some light.
Raising priority: I would like to release 0.11.2 tomorrow with a fix for this one.
FYI: OSX only has CLIPBOARD
, no PRIMARY
or SECONDARY
.
Well, some good news. Testing with your osx builds I can't find any sign of this regression, up to and including r5266.
It's not you, it's us. I'll see about tracking which of our versions is an issue.
Can I close this ticket?
Or are there new clipboard problems? If so, can you bisect?
The same clipboard problem persists in our builds (at least as of our 0.12 r5828 build).
Went through bisection with Smo, the problem came up between r4998 and r4999 as I recall. We still haven't been able to pin down what happened though.
Checking through your beta osx builds - I find that all of them also have the broken clipoard functionality as well now.
Checking through the stable, I find that -
That narrows it down a bit. Unfortunately, looking at the changes in the v0.11.x branch between r5451 and r5643:
$ svn log -r5451:5643 tags/v0.11.x | egrep -v "1 line|---" | sort -u add latest fix to release notes fix video compatibility with ancient clients r5473 for v0.11.x branch: fix nvenc GPU memory leak r5602 for v0.11.x branch: handle all encodings and not just h264 r5624 (and much more) for v0.11.x branch: report correct rgb encoding to client. \ this change required backporting of parts of r5605 r5628 for v0.11.x branch: allow all encodings for the tray r5630 for v0.11.x branch: only remove alpha modes from rgb_formats if we don't handle transparency\! r5632 for v0.11.x branch: tell the server which rgb formats we handle r5637 for v0.11.x branch: scale icon before calling set_from_pixbuf, \ seems to prevent crashes when the icon is very small r5641 for v0.11.x branch: fix webp loading error handler stable version bump updated 0.11.3 release notes update patch context update release notes with latest fix
And here is the link to all these changesets: r5451 r5453 r5474 r5586 r5587 r5603 r5604 r5629 r5631 r5633 r5634 r5635 r5639 r5640 r5642 r5643.
I got those using:
svn log -r5451:5643 tags/v0.11.x | grep "^r.* | .* | .* | .* line" | awk '{print $1}' | xargs
There is nothing there even remotely related to OSX or clipboard, so I suspect that the problem is build environment related.
I've uploaded a fresh OSX 0.11.3 build in the beta area (with the suffix "REBUILD
" to make it easier to distinguish).
Does this one also fail?
r5846 fixes a bug introduced in r5827 (in trying to tidy up, I made things worse!), which would have prevented the OSX clipboard from working properly, exactly as described... but that's long after the problem got spotted (by about 200 changesets), and only affects trunk (0.12.x), so it may just be another bug with the same symptom. In any case, I've also uploaded a new beta 0.12.0 build with this change included, does it help?
The changeset above also adds a simple command line tool to make it easier to test the clipboard change detection code. You can run it with:
python xpra/platform/darwin/osx_clipboard.py
From a jhbuild shell or using the Python interpreter found in the DMG.
I works fine here..
If that also works for you, please try running the client with "-d clipboard
" and post the output.
Testing with what seems to be the latest 0.12 beta (r5846), as well as with our own latest build, the clipboard problems continue to persist.
Testing with your 0.11.3-REBUILD (r5451) with -d clipboard
on, the clipboard problems also persist, and there doesn't seem to be any output in the log (I copied something within in the session firefox window, then pasted it, then copied something from a local chrome browser, tried unsuccessfully to paste it {pasted the same unchanged xpra clipboard contents}, then copied something else on local chrome and again failed to paste it to the xpra firefox window). I'll include the tiny log file.
Even worse, testing with your 0.11.3-REBUILD (r5451) using the GUI launcher, rather than command line... not only does the clipboard problem persist, but now there is a mouse offset problem as well.
I'm attaching a screenshot which displays what was highlighted when I attempted to highlight the word in the orange box. I'm not sure if you want me to collect output with a -d mouse
for you (or even if there is a -d mouse
option supported, or if I am even able to collect such a log when launching with the GUI (using the control channel wouldn't allow collection of any client data, correct?).
basically empty -d clipboard output, REBUILD r5451
screenshot of offset mouse with GUI launcher, REBUILD r5451
-d mouse
to some client code, but the mouse position is *extremely* unlikely to be reported wrong, the server-side window position is likely the problem (visible via xpra info
).
-d whatever
option was added in 0.12: #411, so this won't do anything with 0.11 or older builds. Older builds only support the old debugging technique. ie: using the XPRA_CLIPBOARD_DEBUG
environment variable for clipboard
0.11.3-REBUILD
to verify that the problem is build or packaging related, rather than a bug introduced in the code. Since the problem occurs with two builds of the exact same code revision, this confirms that the problem is indeed build or packaging related. To investigate further:
Xpra.app
from the old DMG somewhere and replace the xpra code (Xpra.app/Contents/Resources/lib/python/
) with the one from the REBUILD
DMG
REBUILD
DMG with older code)
Once we isolate the bug with 0.12, we can worry about fixing 0.11 builds, with a backport if necessary.
PyObjC
library would result in OSX failing the tests for #492 too, r5858 adds an alternative ctypes
implementation for the clipboard changeCount
monitoring code. If the clipboard now works and #492 does not, then we know for sure that the problem is with PyObjC
packaging. If that's the case, it might be worth considering re-writing the PyObjC
code using ctypes
(see for example: pyglet's objc_runtime)
Quick summary: the 'edu' content that it shows the clipboard picking up was a copy from within the xpra firefox window... I tried to copy twice after from local environment .txt file, which seems to correspond to the two local_clipboard_changed() greedy_client=False
outputs. In both cases, when I subsequently tried to paste within the xpra firefox window, the output was that same xpra window copy - 'edu'.
I'll try the copy/swap of the Xpra.app
s and post further...
test of clipboard with r5870 and -d clipboard
Ok, that was quicker than I'd feared.
Xpra.app/Contents/Resources/lib/python
between the two 0.11.3 r5451 builds (the old from your dists/osx/x86
directory into the REBUILD
from the beta, and vice-versa) ... the old/original 0.11.3 clipboard still works as expected (with the python from the REBUILD
), and likewise the REBUILD
still breaks as before the swap of the python
.
What's the next piece to swap?
One bit is still missing:
please post the output of the test script as per comment:7
python xpra/platform/darwin/osx_clipboard.py
(run the script, copy something to the clipboard whilst it's running)
Direct download link: browser/xpra/trunk/src/xpra/platform/darwin/osx_clipboard.py
In the log I see:
ctypes pasteboard access success, current change count=58, setting up timer to watch for changes
So the new ctypes clipboard code has been loaded OK, and seems to detect clipboard changes:
timer_clipboard_check() was 58, now 58 ... 2014-03-20 16:12:03,198 clipboard CLIPBOARD set to 'edu' change count now at 59
At least the ones *we* make.
I also see this:
clipboard_toggled((<XpraClient object at 0x14a37490 (xpra+client+gtk2+client+XpraClient at 0x941200)>,)) \ enabled=True, server_supports_clipboard=True
Do you use the menu to toggle the clipboard? why?
Updating bug title to better reflect where the issue is (this is not a regression in the xpra source code).
clipboard_toggled..
Can be ignored, I think this happens no matter what when we setup the global menu after connecting.
Here's something that might shed some light on this issue: run the 0.11.3 client (both the OK and REBUILD versions) with XPRA_CLIPBOARD_DEBUG=1
and compare the log output. (remember to turn everything else off: no sound, etc)
I tried to run the osx_clipboard.py
tool, after downloading and moving to the Xpra.app/Contents/Resources/lib/python2.7/xpra/platform/darwin
directory, and couldn't seem to succeed in running it.
At first it was failing to import gobject
, some work to make sure it was using the packaged python in the Helpers directory only succeeded in producing this error:
Traceback (most recent call last): File "osx_clipboard.py", line 9, in <module> log = Logger("clipboard", "osx") TypeError: __init__() takes at most 2 arguments (3 given)
... I suppose maybe it should go in a different directory? Or maybe Logger
is too recent and I should run it from a 0.12 (maybe r5870?) Xpra.app directory, while running the 0.11.3 r5451 (original and REBUILD), in order to compare?
Anyway, spent too much time on this to try with the XPRA_CLIPBOARD_DEBUG=1
today, will try as soon as I get the chance.
and couldn't seem to succeed in running it
If you download this script from trunk (0.12) then you usually need to run it against trunk.
Just had a quick look at the older builds:
GTK 2.24.16
GTK 2.24.21
So, it is definitely worth trying to rebuild everything with 2.24.16
and see if that fixes the problem. Also worth trying 2.24.23
(the latest) or even the "unstable" modulesets https://git.gnome.org/browse/gtk-osx/tree/modulesets-unstable.
Assuming that at least one version does work... then this probably needs to be bisected down to the problematic change. We don't want to be stuck on an old GTK version. Another possibility is that newer versions have improved osx clipboard support, and maybe we can drop some of our ugly osx clipboard workarounds. Answering comment:14 should clarify this.
If not:
Any progress? I've noticed a new clipboard warning I cannot remember seeing before:
unhandled format 0 for clipboard data type NONE
r6153 silences it. (use -d osx
or -d clipboard
to see it)
This hints that there have been clipboard related changes in recent GTK versions.
Tried with older GTK by putting
branches["gtk+"] = "http://ftp.gnome.org/pub/gnome/sources/gtk+/2.24/gtk+-2.24.16.tar.xz"
in .jhbuildrc-custom
then extracting it manually when it fails on the hash
Still no luck will try latest next
See also ticket:533#comment:23 about gtk build updates.
Please try a gtk build older than 2.24.14 as this bug seems relevant GtkClipboard unnotified on change of OS X pasteboard owner (this bug is mentioned in the releases notes for both 2.24.14 and 2.24.15..) - maybe this fix is what broke our workaround (we re-use the same change counter). If that fixes it then at least we know where to look.
jhbuild now uses gtk+-2.24.21
Built with this and sent it to afarr for testing i'll reassign this ticket to him for comments.
After retesting with 13.6 r6783 OSX and Fedora 20:
What could be helpful:
If not:
-d clipboard
output comparing a version that does work with one that do not
Xpra.app/Contents/Helpers/Python
for versions that work and versions that don't
Ran some quick tests with -d clipboard with an 11.0 r4998 client against an 13.6 Fedora 20 server. I copied some things into gedit through Xpra, then something different back out into Textdit a few times then ended the session. I'll attach the logs shortly.
-d clipboard output of the server.
-d clipboard output of the client. Copied and pasted from the terminal window.
Can you please post the client log again using the new beta 0.13.8 osx build I have just posted here: http://xpra.org/beta/osx/x86/
If that still fails (likely), please re-assign to smo so he can try to:
Bearing in mind what I've just discovered during #533: it may be necessary to wipe the whole gtk installation directory to ensure that there are no remnants of the earlier builds (this can be scripted to run overnight and deliver multiple gtk installations directories for testing)
Sure enough, testing with the 0.13.8 beta osx client (against the fedora 20 server from your beta dist, 0.14.0 r6936) ... the clipboard works as before.
Attaching client log.
(I launched with an xterm and gedit start-child, typed "123" into the gedit, copied it and successfully pasted locally, then copied something locally - the random string "ting" - and tried to paste it into the gedit. Clipboard pasted the same "123" that had previously been its contents, rather than the new string which it should've acquired from local clipboard.)
Re-assigning to smo.
client logs, 0.13.8 r6939 against fedora 20 0.14.0 r6936, clipboard failure
As part of #533, please try with this patch reverted (on top of latest gtk): pasteboard change.
Raising as blocker.
https://git.gnome.org/browse/gtk+/patch/?id=bc3f1893aa26761c0009ddc993b48623bcfbe4ed
I believe is the commit I successfully reverted this and I will get it out to testing.
Testing... fails. Clipboard still behaving as before (clipboard works within xpra session until a copy is made in the local environment... first copy in local updates the clipboard within the xpra session, but subsequent copying doesn't update clipboard within the session).
Let me know if any logging is of use (might try some as a test of #627 bug reporting tool).
Damn, taking this ticket back.
Does r7231 fix things? Looks like it here. Please confirm and I will backport. I've uploaded a new beta build here: https://xpra.org/beta/osx/x86/
If so, then we got completely sidetracked by this statement from the bug description:
As of 0.11 r4998 the osx clipboard works as expected, by r5144 however, copying client-side..
And then we went off in completely the wrong direction (comment:6 onwards) because I thought we had confirmed that the problem was environment related and not in the xpra code (by rebuilding supposedly OK versions and finding they don't work either).
As can be seen in osx_clipboard.py @ rev 4998, the same bug existed in the revision that was originally supposed to be bug-free. How can it ever have worked? Either it never worked properly, or another bug was somehow hiding this one? (maybe a bug that causes the server to constantly request the clipboard contents? unlikely as it should have been spotted in log samples, but who knows..)
Something went very wrong here and we all wasted a lot of time on this ticket, it would be good to understand what we did wrong so we can avoid making the same mistake in the future. Problem is that I don't see what we did wrong!
First - the good news. osx client 0.14.0-r7231 (your beta) against fedora 20 0.14.0-r7189:
And now for some odd news... it only mostly worked.
For some reason, when using the command-v to paste onto the google.com start/search page... the client woudn't paste. Using the right-click mouse drop-menu to select paste did work though. And the command-v worked to paste everywhere I tried (except google.com start page) on both firefox and chrome.
I collected some client-side -d clipboard
logs. One with a comparison of command-v paste success on another page against command-v fails on google.com, the other with just a comparison of command-v paste failure on google.com against right-click menu paste success at same place on same page. I can't figure out what log info corresponds to what though... so I'll just give you a synopsis of what I did and hopefully that will be enough to elucidate. If not, let me know and I'll try to narrow it further.
ticket507 ... test1:
connected to running session copied text in xpra session (google) (command-c) pasted locally (command-v) pasted within same tab (command-v) copied from local text file (command-c) pasted in same non-google.com tab (command-v) … works pasted in google.com search bar (command-v) - failed pasted in google.com address bar (command-v) - failed pasted in google.com search bar (right-click mouse drop menu) - worked (but appeared in address bar) copied new text from local text file (command-c) pasted into non-google.com window (command-v) - works pasted into google.com address bar, next to previous pasting (command-v) - failed pasted into google.com address bar, next to previous pasting (right-click mouse drop menu) - worked.
test 2:
re-connected to same session copied text from local text file (command-c) pasted into google.com address bar (command-v) - failed pasted into google.com address bar (right-click mouse drop menu) - works
comparison of command-v pasting on working page vs. (non-working) google.com
comparison of non-working command-v pasting vs. working right-click menu pasting, google.com
The Clipboard Worked !!
Backport in r7256.
And now for some odd news... it only mostly worked. worked to paste everywhere I tried (except google.com start page)
That sounds like a different bug, maybe a keyboard bug or a window focus problem.
That's why the Testing the clipboard wiki page uses xclip
rather than adding the complexity of an application layer.
If you can reproduce a problem with xclip, then we keep this ticket open. If the problem is specific to an application, then it needs to go in a different ticket.
I distinctly remember doing reversion tests to see where, after our r4998 version, the clipboard broke... (..) including our versions of some revisions of yours which actually did work
I still do not understand why that would be...
I think we may even have both a broken and a fixed version of r4998 lying around (..)
You can find older versions here too (all versions have that clipboard bug): http://xpra.org/dists/osx/x86/
Not sure what was happening, but it doesn't seem to be doing it anymore.
Just to be thorough, tested again with 0.14.0-r7232 against same server (same running server session, in fact)... and command-c and command-v were working as expected there as well.
Maybe it was just a bad internet day? Whatever the case, I think this ticket can be closed at long last.
Not sure what was happening, but it doesn't seem to be doing it anymore (..)
As to the r4998 with fixed vs. broken clipboards ... would you like a copy of that older one that worked to run a diff?
I have hundreds of builds here already.
Bug. Finally. Closed.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/507