@peternlewis I've been working on an extremely complicated Custom HTML Prompt. 3 times recently, about once a week, I've experienced an issue where Mouse Hover doesn't work properly. When I stop and restart the KM Engine, the problem goes away.
Since stopping and restarting the KM Engine solves the problem, I know it's not a bug in my code. Well, at least not directly.
I don't really have any professional experience writing web apps, so I'm sure I'm doing all sorts of things wrong that could cause Javascript memory leaks. Up until now I just figured that when the Custom HTML Prompt quits, any problems my code might have caused would get cleaned up.
But now I'm wondering if it's possible I'm causing these Hover issues, by corrupting the web environment somehow over time.
What do you think? Does KM clean up the web environment, or do you reuse the same instance(s) that might retain the effects of my poor programming?
No idea on this one. Keyboard Maestro handles the window, but the web view is all system code, handled in a different process entirely, once that does stick around and may well get reused.
As to the cause or the solution, I have not the foggiest idea I'm afraid.
Could be a bug in your JavaScript code, could be a bug in WebKit, less likely but still possible it could be a bug in Keyboard Maestro.
Dan,
I not sure if this is related or solve the problem, perhaps you can try setting the prompt window to non-floatable, and see if the problem occurs again.
I observe that there is a side effect when Custom HTML Prompt window is set to floatable (Always On Top). Once the window lost focus and regain focus, the tooltip, hover stop working. So either need to rerun macro, set prompt to non-floatable or show Web Inspector (oddly, show Web Inspector in a window and return to prompt window, the tooltip, hover start working again until the next time window lost focus).
Though I have to say that floatable window is useful enough for me to ignore these weird behaviours.
Well, stopping and restarting the KM engine always solves the problem (it happened again right after I posted the topic), so there is some correlation. Again, I'm not suggesting that KM is at fault here (not at all), but whatever is going on, it resets when the KM engine stops and restarts.
But I'm not expecting you to delve into this further. I'm just looking for information, and your answer is kind of what I expected. Thanks!
That hasn't been my experience. I can leave it floating, click on KM, then click on the prompt again, and it works fine.
So either need to rerun macro
That doesn't solve the problem for me, and in fact, I lost hours and hours trying to debug my code, running it over and over again, only to discover that stopping and restarting the engine solved the problem.
(oddly, show Web Inspector in a window and return to prompt window, the tooltip, hover start working again until the next time window lost focus).
Again, that hasn't been my experience (not that I don't believe you, of course).
Thanks for letting me know I'm not alone here. It sure is puzzling!
Dan,
thank for letting me know. In fact the issues I mention about floatable prompt happen on my side since KM9. Glad to know that it works for you and possibly others. Up to now, I have no idea what is actually prevent it working on my side.
By the way, how are you implementing mouse hover ?
Yeah, it's always good to know it happens to other people.
Here's the css for my tool buttons:
.btnTool:hover {
transform: scale(1.2);
}
I also have popup tooltips, but I'm popping them up using Javascript animation along with a mouseenter event. Oddly enough, if I remember correctly, even the popup tooltips quit working. I'll have to double-check the next time it happens.
Similar WebKit issues on floating HTML prompts for me:
Highlight on active form select is not drawn
Active text input not highlighted
Stop/Restart the engine does return the expected behavior. Sometimes changing focus (click outside the prompt and then back) restores it.
I'm running Catalina on unsupported (old) hardware, so I haven't pursued this. And I don't really need the highlight as a clue. I know what's supposed to be active and it is.
I forgot about those. They've happened to me also.
I'm running Catalina on unsupported (old) hardware, so I haven't pursued this.
I'm on Catalina also, although not on unsupported hardware. I've got Parallels virtual machines for both Big Sur and Monterey, so if I knew how to reproduce the problem reliably, I could test it under those OSes, but of course I can't reproduce it reliably.
Just ran across an reference to :Focus-Visible by Andy Adams. If that's in the current Keyboard Maestro version of WebKit, it might address these issues. So might an explicit reference to :focus even if the expected behavior is the default.
I love that website! I've learned a lot from it. Unfortunately that won't help in this situation. The next time it happens I'll try to do more research, but it appears as though even "mouseover" events don't fire. And the cursor for my splitter wouldn't change, either. So it's certainly something strange.
