Caprine: cmd+v acts super weird

[mahfysh]

Hi guys, there a really strange issue with pasting staff from clipboard. When I have caprine on I can copy staff anywhere on my mac, docs, chrome, slack etc but sometimes when I am switching between apps using cmd+tab, caprine stays like 'active' in background and when I paste something in other app it's not working, today I found out that I was pasting all that staff to caprine even though my cursor was active on other app. double click - paste always work, there are issues only with cmd+v
-

Caprine 2.5.0
Electron 1.6.7
darwin x64 16.6.0

[marrrc]

can confirm this happens all the time on my macbook pro, too. However, when using Caprine on an iMac i do not have these issues at all.

[jasdev]

Same here. The app seems to hijack my clipboard every so often

[raylin]

Confirm this, the app hijacks cmd+v. I even suspected my keyboard was broken for a while, and at last found all the stuff were in the Caprine's input box.

[IrakliJani]

same here...

[pkosiec]

Me too. It's very annoying!

[fregante]

I found issues with cmd+r as well. It appears that cmd captures caprine.

[veniversum]

@sindresorhus Seems like a bug isolated to macs, I tested on Win 10 & Ubuntu 14.04 and can't reproduce it on either. Might be due to electron-localshortcut failing to unregister shortcuts when Caprine is in the background?

[sindresorhus]

@veniversum That would be my guess too. // @parro-it

[parro-it]

I'm almost there with a 3.0 version of electron-localshortcut based on DOM events that completely avoid globalShortcut usage and would solve all these issues. Unfortunately in this period I'm pretty busy with other non OSS stuff...

I try to call for help on keyboardevent-from-electron-accelerator but I'm unsuccessfull... no one seems interested in helping out...

@sindresorhus It would be beautiful if you could help with your tam-tam superpowers :smile: to call for help...

It could be helpful to try the module on runkit and test that all valid electron Accelerator are translated to a correct D§OM event.....

[thowar2]

Yup, this is a critical issue for me. Caprine is great, but can't keep using it with this issue 😢

[sindresorhus]

New release is out that disables the problematic code: https://github.com/sindresorhus/caprine/releases/tag/v2.6.0

[sindresorhus]

@parro-it I'm wondering why users are suddenly encountering this now. The feature that uses electron-localshortcut has been in Caprine since May.

[fregante]

Perhaps this? https://github.com/sindresorhus/caprine/commit/37ee03b004bea9c5a3cd57773acb5e7028580b32

[sindresorhus]

Yup

[parro-it]

@bfred-it that commit introduce a version of electron-localshortcut in which I start to keep track of window lifetime (minimize/restore, hide/show ecc.).

I did that to solve problem like this one in caprine. Previous releases only cares of focus/unfocus event, so the problem should be there from years afaik... maybe there was some subtle change on how electron manages all these window event?

Anyway. I'm so sorry of the problems the package is causing, but as I said it's a busy period for me...
version 3 should be ready soon that will completely solve these problems, @ewnd9 is helping me and I'm confident it could be a great release!

[parro-it]

For anyone interested in helping solving this issue, I just published a PR on electron-debug that introduce dependency on a pre-release of electron-localshortcut.

This new release implements DOM event based shortcuts management; it could be useful to have someone other test this PR (I tested on Ubuntu 17) and seems to work just fine.

There is some stuff yet to be done: https://github.com/parro-it/keyboardevent-from-electron-accelerator/issues but features already implemented should cover Caprine use case

[sindresorhus]

I've done a new release now with an updated electron-debug. Hopefully, this should finally fix it.

[parro-it]

I checked out this new release on Ubuntu, the electron-debug part seems to work well.

Also, I tryed to uncomment the ctrl-v section.

While we don't override system shortcuts anymore, the feature doesn't work well, since electron-localshortcut does not override menu shortcuts either, and Caprine has an edit menu with a 'paste' item binded to ctrl+v. So the standard paste action is executed just before Caprine overridden one...

I think you should override menu action too, to get it working

[parro-it]

BTW, why use electron-localshortcut here?
Since you have a "Paste" menu, you can just register the action there I think...

[veniversum]

I think the OS native paste with Ctrl+V takes priority over the menu
accelerator binding, at least on Windows. Does the menu accelerator method
work on Linux?

On Aug 7, 2017 3:24 PM, "Andrea Parodi" [e-mail] wrote:

BTW, why use electron-localshortcut
https://github.com/parro-it/electron-localshortcut here?
Since you have a "Paste" menu, you can just register the action there I
think...

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sindresorhus/caprine/issues/258#issuecomment-320589076,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGEBUkw51SU7MasLTM3HMiJlpbcgeko5ks5sVrvBgaJpZM4ObN7J
.

[parro-it]

I think the OS native paste with Ctrl+V

What exactly do you mean?

Does the menu accelerator method work on Linux?

It work, and it seems it is called in parallel with the "paste protection" shortcut.
So, when you press ctrl+v, the image is pasted while you are still seeing the confirmation dialog on screen...

[parro-it]

And if you confirm on the dialog, the image is pasted another time...

[veniversum]

It work, and it seems it is called in parallel with the "paste protection" shortcut.
So, when you press ctrl+v, the image is pasted while you are still seeing the confirmation dialog on screen...

On Windows the CtrlV shortcut is captured by the OS, and the paste command is executed directly. Specifying a menu item with Ctrl+V accelerator does not work, but registering one using electron-localshortcut does. We'll need to handle the different OS separately.

[parro-it]

Do you think I can do something on library side to simplify this use case?