Can not use keyboard shortcuts (cmd+a (select all) / cmd+v (paste) / cmd+x (cut) / cmd+c (copy)) in Webview.
Device information:
- Type of Mac: Macbook Air 2022 M2
- macOS version: 12.5.1
- BetterTouchTool version: 3.870
can you check whether it works with 3.872 alpha (get via "check for alpha version updates")?
Fixed in 3.872 alpha. Thank you!
I'm experiencing the same issue.
These shortcuts all seem to work fine until BTT's clipboard manager has been opened (even if subsequently closed).
After that cut and select all are blocked completely (beeps like a prohibited shortcut), copy silently fails to write to the clipboard, and paste inserts the current clipboard contents into the underlying active app. The only thing that gets them working again is to restart BTT.
@Andreas_Hegenberg is this bug reproducible on your / other systems?
Just to add to my previous post, I've now realised that the same error also occurs with undo & redo (⌘z/⌘⇧z). Any time after the clipboard manager has been opened, both these shortcuts just beep and fail when pressed within the webview. Restarting BTT resolves the issue until the clipboard manager has been opened again.
@sw27 are you able to reproduce any of this within your Searchlight preset or similar?
@Andreas_Hegenberg any hope of a fix please 
? This is all pretty frustrating, especially while trying to debug within the devtools window. For now I've had to implement keydown eventListeners just to block all cut / copy / paste / select all / undo / redo functionality and flash a HUD message reminding me to access it via the context menu instead, which is far from ideal.
Can you try 3.995 alpha? (Currently uploading).
I think I have found a workaround in 3.996! (now uploading)
it working! 
Yes 3.996 seems to do the trick. Thank you!
Hi again Andreas, unfortunately I've noticed since this update that some part of the webview process sometimes keeps running in the background, even after it has closed. I've done some testing between versions, and this definitely only happens since 3.996.
I only realised what was going on as I have a couple of setInterval callbacks monitoring changes to BTT variables, mission control status etc. While debugging, I tested writing data to a file via a runShellScript from within these callbacks, and noticed that the data keeps being written even with the webview closed, albeit the interval timeframe seems to be changed to ~1s.
Specifically it happens after I attempt to call update_trigger on the trigger which toggles the webview, from within that webview itself. I appreciate that this is a very niche circumstance - I'm trying to put together a preset using this webview, and I've been experimenting with checking and enforcing a specific set of parameters for BTTActionFloatingHTMLConfig (ie. updating the dimensions to match the screen size and ensuring that "when run multiple times" is always set to "toggle").
If there's no way around it while maintaining the copy/paste functionality, I can likely leave this check out and just enforce the dimensions via callBTT('resize_webview', { width: screen.width, height: screen.height, x: 0, y: 0 }), albeit without checking for the toggle state. Just thought it worth reporting as it was working fine up until 3.995.
Mhh there really hasn't been any change to the webview. It would be very weird if any of the changes had an effect on that.
Are you sure you didn't accidentally disable the backgrounding option?
But keeping it active in the background might also be a good thing because it would show faster.
Maybe you can disable your intervals in the willShow / willHide functions?
I definitely haven't made any changes to that setting - although I've disabled keeping it active while testing and updating code (albeit the plan is to enable background and preload once I'm happy all the code works). I had completely overlooked the lifecycle stuff you mentioned tbh, so I'll experiment with that later and let you know if I'm unable to resolve it - thanks for pointing me in the right direction.
My bad - I realised at some point I must have changed "Specify position" from "Relative to bottom left corner of main monitor" to one of the non-absolute options and that's what was interfering with my code for re-triggering the webview after updating its BTTActionFloatingHTMLConfig.
When I went back to test on previous versions, BTT was obviously loading one of its cached backups so it took me a good long while to realise what exactly I'd changed!