Thanks for the report. Unassigning and marking as Untriaged so we can discuss it at triage.

I'm having trouble understanding the procedure - please could you give more detail, observing the following points?

* Clarify which actions occur on the client or the host.
* Break down "copy multiple items" and "paste multiple things" into lower-level steps.
* Specify which actions involve ClipMenu, and explain how to use that app to perform the action.

Thanks!

Grr, I looked and looked for a remoting component but I guess never thought to look for Chromoting :S.

Attached a video of me trying to paste multiple things.

Deleted: ClipMenu.mov 7.1 MB

ClipMenu.mov 7.1 MB Download

Video is really helpful, though I had to watch it about 20 times to figure it out :)

In our usual terminology, Mac OS X is the *client* OS, not the host. The Chrome Remote Desktop client app is being used to connect to the Ubuntu *host* desktop.

Here's what I think is going on:

You are trying to 'copy' the local OS X clipboard content and paste it into the remote Ubuntu session.
ClipMenu (running locally on the client) has a history list, which you've pre-populated with some items.
When you select an item from ClipMenu's history, that selection is placed onto the local clipboard (as if you had locally copied the same text in an app).
When you try to paste into the remote Ubuntu desktop, it doesn't work correctly. It appears that newly-selected items from the history list don't get sent over to Ubuntu.

Here's my guess of why it fails:

I think that you are somehow managing to show ClipMenu's history list, without window-focus leaving the Chrome Remote Desktop app window.
You select another item from the list. The local clipboard is changed.
But Chrome Remote Desktop client never notices the change, because the window doesn't gain focus. The CRD client only checks for a changed local clipboard on window-focus event.

Why only check on window-focus? The Chrome APIs don't allow us to be notified of local clipboard changes. All we can do is query the current clipboard text.
The rationale is - in order for a user to copy text from another app, they have to:
1) switch away from the CRD app,
2) copy the text,
3) switch back to the CRD app,
4) try to paste into the remote desktop.

It's at step 3 (CRD app gains focus) where CRD actually polls the local clipboard and sends it over to the Ubuntu host. By the time you do step 4, the content is on the remote Ubuntu clipboard, ready to paste into an app such as gedit.

I suspect ClipMenu breaks this assumption, by not de-focusing the CRD window when you select a history item.

Could you test this? Try using a method that shifts focus away from CRD? Or after selecting a ClipMenu history item, try switching away from CRD to another app, then switch back again?

Tried it out and can confirm that switching apps causes the clipboard to be updated as you described. Specifically:

1. command-shift-v to bring up clipmenu
2. Choose an item
3. Wrong this is pasted
4. Focus another window
5. Focus chromoting
6. Ctrl-V to paste and now selected item is pasted.

Thanks for confirming. So this is a use-case where read-clipboard-on-window-focus is broken.

I'm not sure if this is something we can fix? We might have to do regular polling for clipboard changes, which probably is not a good trade-off. There is work going on to improve Web Clipboard APIs, but that will take time.

The right long-term fix is to implement clipboard notifications for the web, which is something we're looking into. In the shorter term, I wonder if we get a mouseleave event fired in this case? We could hook that as well as blur/focus if so.

I think you mean mouse-enter, not mouse-leave? We poll the clipboard on window-focus, so it could make sense to do it on mouse-enter as well?
It would be a very easy change and it might work in this case, but if the user does the entire copy/paste with keyboard-only, it still won't be enough.

Using this test page: https://dvcs.w3.org/hg/d4e/raw-file/tip/mouse-event-test.html, I did not see any events when executing a paste.

But, using: http://unixpapa.com/js/testkey.html

And activating the ClipMenu paste, it does show some keyboard events coming through:
keydown  keyCode=16        which=16        charCode=0        
keydown  keyCode=91  ([)   which=91  ([)   charCode=0        
keyup    keyCode=16        which=16        charCode=0        
keyup    keyCode=91  ([)   which=91  ([)   charCode=0        
keydown  keyCode=86  (V)   which=86  (V)   charCode=0        
keyup    keyCode=86  (V)   which=86  (V)   charCode=0        

The first 2 keydown & keyups are for command and shift (to summon the menu). But the "V" happens after selecting an entry. You can actually notice this oddity in the video, where instead of pasting, it enters a "v" in the field.

Not sure it's general enough to cover other clipboard managers, but in this case it might be enough to listen for a "command-V" and hook that up to a "sync the clipboard then execute a ctrl-V".

Syncing on Ctrl/Cmd+V might help in some (most?) cases, but it won't help with paste operations carried out using a menu. It will also delay the keypress event, since the clipboard API is asynchronous, although the effect is unlikely to be noticeable compared to the network latency. Overall, I don't think it's worth implementing, given that a better API is in the works and our current work-around works in most cases.

I'm happy to wait if the better clipboard api fixes this issue, but just want to see if you think it'll address both sides of this problem:

1. Is that the clipboard contents doesn't get synced. Sounds like this will be addressed.

2. Is that it inserts a "v" rather than performing a paste.
In all other apps, selecting an entry in ClipMenu causes the "Edit" menu to flash blue and for a paste to be executed. In CRD, the menu does not flash blue and instead of a paste being executed, the letter "v" is inserted.

You're connecting to a Goobuntu host; correct? In that case, it won't work because ClipMenu assumes that the correct key sequence to paste text is Cmd+V, whereas Goobuntu expects Ctrl+V. Actually, it's much more complex than this because there isn't really a single "paste" keyboard shortcut on Linux--Terminal expects Shift+Ctrl+V and emacs expects Ctrl+Y, for example.

If you're connecting to a Mac host, then it might work (modulo pasting the wrong thing). However, it's also possible that ClipMenu synthesizes Cmd+V as a single keypress with appropriate modifiers set. Since Chromoting assumes a physical keyboard, I don't think it will handle this case correctly.

Ah okay, I think you're right. Just tried virtualbox and parallels, and neither of them "just work" either. VirtualBox captures the shortcut (menu doesn't appear). Parallels allows the clipmenu to appear, but just inserts a "v" like CRD.

Thanks for working through this with me! 

Hopefully we'll have an API to detect local clipboard changes eventually. I don't think it's worth trying to work around this until we have it.