(KM10) Fix for Custom HTML Prompt Action for Script Which Returns Incorrect windowscreenX & screenY Values [Tips:KM10]

Issue:

Window.screenX & screenY not producing correct location in KM10
For those users whose script in Custom HTML Prompt Action is using window.screenX & screenY api to save the location of window and to be restored later, take note that the API that works previously in KM9 no longer work correctly in KM10. It will return the wrong value ( eg 0 for x, wrong value for Y)

Solution:

This WKWebview issue (which KM10 is using to replace the old webview) is confirmed by Peter who suggest the fix is to use WINDOW(Left) for X and WINDOW(Top) for Y in KM10 . The window function is found in [function:WINDOW [Keyboard Maestro Wiki]].

However I have put forth a seamless fix that just need to be added to any script that use screenX and screenY. You can test it by running the attached javascript file in Custom HTML Prompt action.

(Probably this fix should be added into KM engine by Peter so users don't have to be manually add to their script ? ) - Have confirmed with Peter that he prefer to wait for Apple to fix this WKWebview issue, so the meantime, if anyone that want to fix the issue in their script easily, they can just add that fix at the top of script.

The fix is adding the following at the top of the script to override the screenX and screenY read accessor.

(function fixWindowScreenLocIssue() {
      Object.defineProperty(window, "screenX", {
         get: function () {
            return parseInt(window.KeyboardMaestro?.Calculate("WINDOW(Left)")
                  ?? window.screenX);
         }
      });

      Object.defineProperty(window, "screenY", {
         get: function () {
            return parseInt(window.KeyboardMaestro?.Calculate("WINDOW(Top)")
                  ?? window.screenY);
         }
      });
})();

To test the effect of script , just toggle the variable "useFix" , as the window move, the location info will be updated.

get_window_location.html.zip (1.2 KB)

[Script Modification History: 10 Nov 2021 12:53 pm US time] – Add parseInt to read accessor as window.KeyboardMaestro?.Calculate function return string. Actual result should be number type not string.

3 Likes

I haven't tested this yet, but what an awesome solution! I do agree with Peter that he should wait for the fix from Apple, but regardless, this is some great code. Thanks for posting it!

Hi Dan,

Np.

Javascript is very fun and hackable language to program in :}

But I not too sure if Apple is going to fix it as the issue is reported since 2017:

171841 – In a WKWebView app, window.screenX and window.screenY are garbage

Let's hope someone in the forum who has access to the relevant Apple engineer may help to expedite the fixing...

In the meanwhile, enjoy the fix.

1 Like

You can say that again!

but I not too sure if Apple is going to fix it as the issue is reported since 2017
171841 – In a WKWebView app, window.screenX and window.screenY are garbage ,

Let's hope someone in the forum who has access to the relevant Apple engineer may help to expedite the fixing...

Thanks for the info, and I agree.

In the meanwhile, enjoy the fix.

Absolutely. BTW, if you ever have any thoughts on anything JXA/JS I've done - improvements, questions, criticisms, I'd love to hear them. I'm just fuddling my way through this stuff. I mean, I have a professional programming background, but I never did any work in JS until I started working with KM. So it's like working in a vacuum. So like I said, feel free to hit me up one way or another. Or not - that's cool too.

Np.
The key to my learning is to keep experimenting and exploring new way of doing things.
I too didn't actually use Javascript seriously until I start developing KMApp (app that primarily use Custom HTML Prompt action in KM). I didn't quite like those heavy weight solution in Electron and web app if all I need is utility that just need to be use fast and close fast. Web App development getting so complicated nowadays with sophisticated build and transpiling that take away the fun of development. I glad Keyboard Maestro solution exists in the form of Custom HTML Prompt action to make development fun and pure joy.

The most interesting thing that KM taught me over the years is to appreciate the use of many languages, unix command line utilities, and be polygot programmer because KM with its execute script actions can leverage on any languages, ecosystem, tool and so on and on .The only limit is our imagination and creativity. When all these come together to produce a solution, it simply magical.

We have platform like mobile app, web app, and desktop app, and I will say the next wave will be macro app ,and KMApp will fall under that category. I now rely on building KMApp continuously to improve productivity and to exercise creativity.

One area worth exploring is running on app server with Custom HTML Prompt which I already did for many of my apps, so I running Custom HTML Prompt together with node.js server app. So more functions can be placed on the frontend. It is slightly more complicated but to see it run is a feeling that is hard to describe :}

Awesome post, and I agree with most all your sentiments. I've stayed away from node.js, but perhaps I should look into it (although it's not like I have a ton of spare time).

I understand the feeling you get when the server stuff comes together - I did some backend development (in C#/.NET) in my prior life. The whole idea of "black boxes" that you hand stuff to and get something back is one of my favorite aspects of programming.

In woodworking, I like to "make stuff to make stuff", and the same is true in development - I like writing stuff that makes programming easier. Hence things like KMFAM.

I'm rambling, and I need to finish a video. :grinning_face_with_smiling_eyes:

Thank you! This has been bugging me forever!

1 Like