I am using a "custom HTML prompt" (chp) activated by a KM-Macro in a macro group, which is available only if the (e.g.) Music.app is running. When the chp is displayed first, all :hover-elements in the chp work fine and show their defined css-markup-behaviour. But once I click in the Music.app and then again in the chp (i.e. defocus and focus it again) I loose all css ":hover-functionalities", i.e. all html-elements in the chp work as if there were no :hover-markup at all.
There is also another behaviour, which may be connected with this behaviour and which I would also like to understand: When the chp is activated, the Music.app is running and at front (red, yellow, green Control buttons) [because the macro which activates the chp is only then available]. Once the chp is displayed and focused, the Music.app looses its focus. So far very logical. Then clicking in the Music.app, the Music.app gets focused and clicking again back in the chp, the chp gets focused, but the Music.app does not loose its focus and both windows have red, yellow and green control buttons (the Music.app is displayed in the menubar). Perhaps, since the Music.app still shows ":hover"-functionality on its elements which are designed for it, the chp did not get back its own :hover-functionality. But clicking in on those two windows, there is no way, that Music.app looses its focus. Nevertheless all other (css/javascript-) functionalities work fine.
Could anybody explain to me, why ":hover-functionality" in chp does only work until it is defocused for the first time?
In a word: WebKit. A few of us who write Custom HTML Prompts have noticed various issues with the newer version of WebKit included with Keyboard Maestro 10. Restarting Keyboard Maestro seems to restore the expected behavior.
I experience the same problem but if you disable Floating, it may work if return to focus ( some custom prompt window may need to have floating for good user experience though). The problem is inconsistent as some may not have this issue with Floating enabled.
thanks mrpasini and macdevign_mac for your reply. Restart of KM-Engine does not solve the problem. I tried also the non-floating chp, but I experienced exactly the same behaviour. With Non-floating chp I have also the problem to bring the chp-window to the front (if it is covered by other application), since all KM-actions (using the 'Window ID' of the chp) does not work to bring it to the front and as far as I know with javascript within the chp you can not set the window into focus. Thus I mainly work with a floating chp. Anyway chp is a great tool and you may be right that this is a webkit problem.
I have an M1 and an Intel. It's wild speculation to think that Webkit might behave differently, but it's an idea. This is the kind of bug that I suspect could be hardware dependent.
Do you have something simple that you want me to test for you?
yes, just create a macro group which is available in any one of your application. In this macros group create a macro with just a very simple chp with may be only a link test and a style "a:hover {color:red;} and give it any hot key to call.
Then after calling check if the hover work, switch to your (available) application and click back to your chp and see if hover still works. If you do not see any difference on Intel and M1 then this may not be chip-dependent. Thanks for your offer.
I've discussed this issue with Peter, and he's pretty sure it's not a KM issue. I'm surprised that restarting the KM Engine doesn't help. I mean, I suppose it could be related to the M1, but it seems unlikely. Does rebooting make a difference?
I spent many hours trying to track down this problem, thinking it was my code that caused it. And during that testing, I got inconsistent results from changing async, floating, etc. Sometimes I thought I had narrowed down the problem, but in the end, it was all just noise. I couldn't find any direct correlation.
Boy was I glad to discover I wasn't the only one with the problem, because I was starting to pull my hair out.
It always gets fixed, for me, when I stop the KM engine, then restart it. But it wouldn't surprise me if the Webkit might get screwed up enough to require a reboot.
I'm happy to try to help you after my upcoming family meeting, but I can't create a Custom HTML action without the code itself that you want me to test. That's because I can't translate your words above into HTML because I'm not very good with HTML.
Thank you very much, macdevign_mac, for your work. Yes, this is a good example, which show exactly my problem. If you put this macro in a macro group which will activate it when another app is running, then my test runs as follows:
call your macro and check the hover. Yes, it works
click to your application which needs to run to activate the macro group and
click back to your chp and check the hover. No, it does not work
If you have a different behaviour, this would interest me. Thanks for your help.
Dan, thanks for your reply. For me its also good to hear, that it is not only my problem and it seems not to be my simple misunderstanding how chp works. Rebooting does not make any difference.
As I understand the chp is created by the built-in webserver of the KM-Engine and you can give (with data-kmwindowid= in the -element) a window ID to the chp. But when trying to use this window ID with other KM-actions (e.g. bring window to the front) KM reports "can't find the window with ID...). Thus I would like to learn more on how the chp is constructed. It did not see this behaviour on my own (local) webserver with similar construction although they are all displayed within Safari.
Sleepy, thanks again for your offer. In the mean time macdevign_mac has constructed a very good and easy example, which could demonstrate the problem very well and it is no need for you, to build another one.
I was in a family meeting for the last hour. I'm not sure if I can get this done in the next 10 minutes before I have to go out for an hour.
EDIT: I'm struggling to make the hover feature fail, probably because I don't know what this means: "click to your application which needs to run to activate the macro group". I have to leave for an hour, I'll try again when I get back.
I don't know exactly how that works, but it uses the macOS "Webkit" to do the work. Peter made it sound like he doesn't have to do much to use the Webkit.
Yeah, same here. @peternlewis, do you know why we can't use either of these to bring a Custom HTML Prompt to the front? (the second action uses my "data-kmwindowid"):
I'm back, and while I'm happy to help and happy he uploaded the code that he wants to test, I'm still struggling to understand how to test this. Here's what I did after downloading his macro:
I activated the Custom HTML window from the KM status menu.
I hovered the mouse over the line items and the blue line moved with my mouse.
I got stuck on the line "click to your application which needs to run to activate the macro group" because I don't know what application he's talking about. Is there supposed to be an application listed in the properties of the group, and I'm supposed to use that? He didn't include any application there in the group & macro he uploaded.
Whenever the Custom HTML window is the selected app (even though its name doesn't appear in the system bar) it works fine. I don't understand how I'm supposed to get it to fail.
Sleepy,
"click to your application which needs to run to activate the macro group" means that should one install the macro I uploaded under a specific-application macro group, then the macro is trigger-able only when the application is in focus.
So to test my macro, one should just
Hover the row (it should turn blue)
De-focus the Custom Prompt Window (by making other application in focus/active)
Return back to the prompt window, and hover again to see if the row able to turn blue
When you say "return back to the prompt window" do you mean click on it (ie, does "return" mean "click")? Until now that's what I thought you meant, but now I'm thinking you may mean do NOT click on it, and that you expect the hover feature to work when the Custom HTML window is NOT the active window. Is that what you want? In that case, it does fail on my M1 Mac, and I can go test it on my Intel Mac if you want.
