Any way to prevent Max jweb object from passing all keyboard input through to Live?
tl;dr: I have a jweb object in my patcher with a custom UI implemented as a webpage, but it's unusable since keypresses get passed through to Live, so for instance if you hit spacebar, it does input a spacebar in the jweb page's textarea, but it also sends play/pause through to Live.
Is there a setting or a workaround to make this work?
Details:
Interestingly, if you set jweb render mode to "onscreen", every single keypress is passed to both the patcher and Live (i.e. pressing "a" inputs an "a" in the jweb page but also toggles Automation Mode in Live), but if you set jweb render mode to "offscreen", most keypresses are not passed through to Live, but spacebar is. In all cases, command shortcuts are intercepted and don't work in the jweb page (i.e. you can't press cmd+c to copy in the jweb page, nothing happens).
I've tried using JS to capture keypress events and do preventDefault and stopPropagation, but that doesn't help.
This happens in patcher popouts too, and I've tried various window flags like float, but it doesn't help.
If you open the patcher in the Max editor, it works as expected: jweb captures all keypresses and shortcuts and they're not passed through to Live.
Textedit objects of course work as expected.
This problem only happens on Mac, works fine on Windows.
To reproduce, you can simply add a jweb object to a patcher, pointing to google.com, and test by typing in the search box.
This is tricky one and I guess this needs help from the Cycling 74 / Ableton support.
What is strange that this only happens on the Mac and not on Windows - as I like to work on Mac too, I am interested in this phenomenon too, but unfortunately I have currently no idea how to circumvent it.
The only thing that came immediately to my mind was : window specific event loops.
In the sense of what ever input device you are using, keyboard, mouse or another HID like a joystick (or even Bluetooth connected input devices), its inputs are routed to the current active window (the one that has focus from the operating system perspective) and its event loop ... and I am (was ? ;-) quite sure that this is operating system independent.
So its astonishing that using pcontrol (I guess that is what you meant with patcher popouts) does not change the behavior, as it should have its own event loop, whereby I am not sure if the fact that there are several windows that belong to 1 parent process (in your case Live) changes the rules and let the application decide what to do.
And this might be operating system depended or they just implemented it differently for MacOS and Windows - in the sense that there is a event dispatcher on the main window that is tied to the process which allows the app to route the events ... or in other words : there is only 1 event loop per app process and not per window (its a long time ago I had to work on this level / UI framework layer).
This might explain why Live and the Max editor behave differently - they are different apps / parent processes and hence might decide differently how to route the events.
If you ask the Cycling 74 or Ableton support, as this happens in their "domain", and get an answer from them, it would be great if you post their answer or its essence here, as this problem is a tricky one ... these kind of quirks Max patchers most probably stumble upon in the last steps of the (M4L device) development process and hit the wall just short before being able to use it.
So its important that we as Max users share this information to be aware of the limitations we might face upfront - as nothing of these important kind of things are documented anywhere.
Thanks for your thoughts, I agree it's very strange that it happens even using pcontrol (yeah that's what I meant by patcher popout). Even when using pcontrol the Live app still has focus, but opening it in the Max editor of course Max now has focus so it makes sense that the bug doesn't happen in that case. I think the difference between onscreen and offscreen rendering is also strange.
I've contacted Cycling 74 support about this, will see what they say.
Also, for slightly easier repro for anyone else, here's a patch with jweb that makes it clear:
(save the patcher and drag it onto a track and use in the device bar to see the bug)