Any of your buttons has the Focus? AFAIK you need the focus in a control on your page so Enter/ESC activate the Default/Cancel buttons.
If you can add a WebTextField, run your project, click on it and then press Enter/ESC, should work. Or if you click the last button, so it gets the Focus, then you can press Enter/ESC
In my test I was starting the app and pressed either Enter or Escape. I clicked on the regular button - I see a ring around it after and then pressing a key worked. But that’s not true for a WebPopupMenu: once you picked a choice it does not have the focus anymore. But if you click the PopupMenu and then press a key, it works.
This is a strange implementation of Default and Cancel buttons, where you need to have the focus set on a control. It may fail on you, for example the PopupMenu. Will that be fixed in the next version ? It can be nice to have Default and Cancel buttons, but it does not seem flawless for now.
What do you want to get fixed? That pressing Enter/Esc activate the buttons even if no control has the focus (ring around)? I don’t know there is a Feedback for that, without feedback case the behavior will not change.
To me, looks like the app does not listen to key strokes on the WebPage, only on Controls
The PopupMenu does not keep the focus, meaning that if it’s the last used control, Enter and Cancel will not work.
Having to make sure a Control has the focus, as long as it’s not a PopupMenu means the app must arbitrability find a control to set the focus on, which may puzzle the user.
Is this the behaviour for other Web apps as defined mby the standard ?
It’s not that. The ability to recognize the Default and Cancel actions is tied to the Tab engine because it was found that users sometimes liked to have multiple buttons marked as Default and/or Cancel. This scenario also happened with Dialogs since they are after all still just controls on the same web page, just wrapped in another area of the screen. What all this means is that the automatic actions are based on the “context” of the current tab group.
Think of tabbing as a hierarchy, where every control that can contain other controls as a subgroup of its parent, when a key is pressed, let’s say TAB, the system looks at the current group to see where the focus currently is and if there are any more tab-able controls left. If so, focus goes there, if not, control is passed to the parent and it does the same lookup, and so on, until a focusable control is found.
When ESC, RETURN or ENTER are pressed, a similar track is followed except that what it’s looking for are buttons which have the Cancel or Default action applied.
All of this relies on the system knowing where the focus currently is.
Since having Default and Cancel buttons is not a defined standard, their implementation is left to the developer, in this case Xojo for the main part. And the Xojo (developer) user has to handle special cases like the PopupMenu that does not keep the focus.