I noticed that variables in my HTML prompts no longer work in Sierra. Example:
<input name="myVar" type="checkbox" accesskey="i">
myVar, which is a KM variable, is ignored. The macros run fine under El Capitan.
Any idea?
PS: I’ll post a more complete example when I’m back this evening.
I don’t have Sierra, so I can’t answer directly. But if needs be, you can always initialize the fields and return the results manually. That’s actually what I do in virtually all my HTML prompts, and it’s pretty easy.
I know this isn’t the ideal solution. But it is a solution. 
What I mean is this:
This is a minimal working example:
HTML Prompt Test.kmmacros (2.7 KB)
On my Mac with El Capitan the prompt shows me…
On my Mac with macOS Sierra: nada.
Both with KM 7.3.
Yes, I understand what you mean. But you can get something working by doing something like this:
HTML Prompt Test.kmmacros (3.1 KB)
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<script type="text/javascript">
function KMWindow() {
document.getElementById("ωMyTmp").value = window.KeyboardMaestro.GetVariable("ωMyTmp");
}
function submitWindow(result) {
window.KeyboardMaestro.SetVariable("ωMyTmp", document.getElementById("ωMyTmp").value);
window.KeyboardMaestro.Submit(result);
}
</script>
</head>
<body>
<form>
<p>
<label class="label">Set Variable:
<input id="ωMyTmp" name="ωMyTmp1" type="text" autofocus>
</label>
</p>
<div>
<button name="OK" class="button-default" onclick="submitWindow('OK')">OK</button>
</div>
</form>
</body>
</html>
Many Thanks, Dan. Indeed this works with Sierra.
Some questions remain:
I have no idea why they don’t work. I’m sure Peter will fix the issue eventually.
Should you change all of your prompts? That’s up to you. The changed prompts should continue to work even when the issue is fixed. I guess it depends on how much you need them.
For some reason, I’ve coded almost all my HTML Prompts this way. Sometimes I have to massage the data before I display it, so I guess I just got used to doing it that way. I guess I got lucky.
No, you are wise 
Not in this case. It really was luck. But thanks for the vote of confidence.
Dan, your method above worked smoothly for text objects, but then I had some difficulties with checkboxes:
The variable ωMyTmp is 1 or 0 in KM.
I now can set the checkbox status in the prompt with…
document.getElementById("ωMyTmp").checked = +window.KeyboardMaestro.GetVariable("ωMyTmp");
and I can submit the new value with…
window.KeyboardMaestro.SetVariable("ωMyTmp", document.getElementById("ωMyTmp").checked == true ? "1" : "0");
This way it works now with macOS Sierra, but it seems very clunky to me and I’m almost sure there is a better and simpler way…
Thanks for any hint.
Here is a commented MWE:
Well, that looks OK to me. I mean, you could write some functions to convert between string and boolean values, or create some Prototypes or something, but that basically works.
I started writing some functions as an example, but I could come up with 3 or 4 different versions without even thinking about, so it all depends on how you want it to work.
OK then. Thanks for your help!
Yes, it appears there is a subtle change in WebKit in Sierra which stops the automatic reading/writing of variables in Custom HTML Forms.
Do you have plans to fix it? If Yes, I’ll stop adapting my HTML prompts 
Yes, certainly. The question is whether for 7.3.1 or 8.0.
I’m starting to lean towards the former, but I am trying to start working on the latter.
Well, I thought of some kind of a hot fix, since the change effectively makes all HTML prompts dysfunctional. (At least for people like me who were relying on the automatic reading/writing of the variables.)
I don’t know what you mean by a “hot fix”. The fix requires a new version of Keyboard Maestro, which means testing, which is problematic as I have since updated to Sierra and Xcode 8, so the entire development system is different which could result in any number of subtle defects that I wont find out about until afterwards, or alternatively means booting back under El Capitan and building and releasing there, which has its own set of risks and drawbacks.
So all of that has to be weighed against fixing whatever bugs or Sierra issues appear, since the cure could be worse than the disease.
I’d like to put in a vote (FWIW) to put this in 7.3.x. While I cannot say it’s made the custom HTML prompt useless, it has made it a giant pain to get it working properly to have to set up scripts to automatically populate fields and submit them.
For a stopgap measure, here’s a script block you can put into all your HTML prompts to get things mostly working. These scripts looking for elements with the “data-kmvar” attribute, and pre-populate or submit/set those variables based on the individual element’s name attribute. You will also want to call the submitWindow() function for your submit button rather than rely on directly calling the submit handler.
So this will require you to change your HTML from:
<input name="varFoo"></input> <br /> <input type="submit" value="Submit" onclick="window.KeyboardMaestro.Submit('submit');" />
to:
<input name="varFoo" data-kmvar="1"></input> <br /> <input type="submit" value="Submit" onclick="submitWindow('submit');" />
Not too hard. Won’t work really well for non text input fields, but that’s no different than before.
Here’s the script block:
<script type="text/javascript">
function setKMFields() {
var kminputs = document.querySelectorAll('[data-kmvar]');
for (i = 0; i < kminputs.length; i++) {
kminputs[i].value = window.KeyboardMaestro.GetVariable(kminputs[i].name);
}
}
function submitKMFields() {
var kminputs = document.querySelectorAll('[data-kmvar]');
for (i = 0; i < kminputs.length; i++) {
window.KeyboardMaestro.SetVariable(kminputs[i].name, kminputs[i].value);
}
}
function KMInit() {
setKMFields();
}
function submitWindow(result) {
submitKMFields();
window.KeyboardMaestro.Submit(result);
}
</script>I am working on 7.3.1.
Version 7.3.1 resolves this issue.