I used the original Karabiner app 10.22 and could very precisely restrict any actions via Apple's Accessibility Inspector to work for specific dialogue windows.

This is no longer possible with Karabiner Elements.

So in order to (in Safari) click the context menu's item "Element Information" (which I use very often) I tried this code in "Complex Modifications":

 "to": [ { "pointing_button": "button2" },
         { "key_code": "e" },
         { "key_code": "return_or_enter"}  ]

Which did work, but alternately only opened/showed the context menu or actually executed "Element Information".

By experimenting, I found a workaround that mostly works for me:

"parameters": { "basic.to_if_held_down_threshold_milliseconds": 50 }, 
"to":       [ { "pointing_button": "button2" } ],
            [ { "key_code": "e" },
              { "key_code": "return_or_enter"} ]

My questions:

Why are not all "commands" in the first code example executed in due order (or: only alternately) and (more interestingly:) how can you ensure that each "command" is executed every time?


I think your workaround perfectly demonstrates the reason: you are selecting "Element information" via the GUI, and the context menu may take a few milliseconds to be brought up. This isn't an issue with Karabiner specifically — if the E and return keycodes are sent instantaneously after right-clicking, the context menu may not be in focus yet, and they won't be directed appropriately.

In short, if you're making a GUI macro, you may need to wait for the GUI to respond.

As I see it, there are three possible solutions:

  • simply add a brief delay, as you've done,
  • use an alternate tool (e.g. Keyboard Maestro) which allows you to pause until a certain condition is filled, or
  • use an alternate method of activating the desired outcome, i.e. something which doesn't rely on the graphical user interface at the user level, such as AppleScript (though I don't know if such an option exists for this specific goal).
  • Thanks a lot for your answer, that addresses the first part (why) of my question; the second part (how2) still is what is most interesting in order to get a fail-safe method (not depending on cpu, RAM etc.). I cured the "why" with my workaround, but this will not work on every computer, maybe not even on my own if too many apps are working simultaneously. I vote your answer up one, so if nobody finds a how2-answer, you'll get the bounty ... :-) – clemsam lang Oct 15 '18 at 6:19
  • [ADDED TOO LATE:] … if s.o. else "agrees" … :-) – clemsam lang Oct 15 '18 at 6:26
  • @clemsamlang I've added my reply to my answer, since it didn't fit nicely in a comment. :) – Timothy Mueller-Harder Oct 15 '18 at 6:51
  • – I appreciate this … you don't happen to have an idea, how K-E can be made to actually WAIT for a GUI event? – clemsam lang Oct 15 '18 at 10:25
  • @clemsamlang I’m not very familiar with the scripting side of KE. I’d have to do more research. – Timothy Mueller-Harder Oct 15 '18 at 18:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .