Bug when switching apps in different desktops pressing cmd+tab in macOS

Bome Products
,
30

In this example preset 1 is looking at incoming keystroke which I think is what you were reporting as the problem but it seems to be interpreting things right. Keep in mind the when you use incoming keystrokes, they will not be suppressed by the OS so if you are sending different keystrokes, the OS will see a combination of both.

testcmd.bmtp (1.9 KB)

1: 1.0:1 Log CMD Pressed
2: 1.2:1 Log F12 Pressed
3: 1.3:1 Log F12 Released
4: 1.1:1 Log CMD Released

Steve Caldwell
Bome Customer Care

Also available for paid consulting services: bome@sniz.biz
32

I have installed the new release 1.9.2 (build 1087) and I confirm that this bug is still occuring.

I suppose you have forgotten to fix it, as it seems for the replies of Steve that you don’t know/remember what the problem is.

Frankly speaking, I’m very disappointed that you haven’t fixed this bug after more than 1 year of reporting it.

33

Hi Jordikt, thanks for testing. I can fully understand your disappointment.

I’m not sure how you draw these conclusions here. We don’t forget bug reports. But we do prioritize them, according to a criteria like:

  • how many users are affected (how many users have reported the same issue)?
  • is it a regression (i.e. has it worked in a previous version of MT Pro?)
  • is there a workaround for the user?
  • is it an actual bug in MT Pro or a shortcoming in the OS, or a feature request?
  • can it be reproduced by us?
  • how hard is it to fix it?

As Steve pointed out, this Cmd-Tab problem is in a grey zone between OS limitations and MT Pro capabilities. From user point of view, it certainly seems like a bug, but it may also be that our valid implementation just does not work because of MacOS. In these cases, it may be possible for us to add a workaround so that it works, but that’s usually much more involved than ‘just’ fixing a bug.

I know all this does not actually help you. But I hope it explains a little bit why some bug reports take longer to be worked on than others. Sometimes, it may not be possible to fix a reported problem at all.

35

I appreciate your words Florian, just as I appreciate Steve’s.

However, I was told in this same thread that the bug had been detected and would be fixed in the next update.

But now you tell me that the bug is not fixed, and also that you can’t detect it, and that maybe it’s not even a bug, that it’s macOS’ fault.

I can confirm 100% sure that it’s a BMTP bug, because macOS’s modifier key detection is 100% reliable. There are many apps on the market that detect, monitor and control the shortcuts that a user uses globally in macOS or for specific apps. None of these apps have the problem of confusing that the CMD key is pressed after releasing the shortcut ⌘+tab.

I myself have developed a small app that runs in the background to detect when BMTP makes a mistake in detecting the CMD key and sends it a CMD down-up key to fix the problem. So I have already developed a workaround for this bug. Anyway, I would prefer to stop running this small app and use BMTP without this bug.

____________

I understand that developers have to choose which bugs to fix and which not to fix, and which you can fix and which not.

And I understand that there are many minor bugs or feature requests that you receive and that you cannot implement everything to please users.

However, to me, this bug does not seem like a minor or standard bug. And I do not say this because it affects me. Due to the consequences it has, for me it is a serious bug and therefore it should be a priority to fix (although surprisingly no one else complains about this problem).

____________

Finally, I want to make it clear that the main cause of my disappointment is that I have been informed that this bug had been replicated and that it would be fixed in the next update. Now I’m being told the opposite, that the bug can’t be replicated, that maybe it’s macOS’ fault, and that it will probably never be fixed because it only affects me.

This radical change in stance you’ve had regarding this bug is what seems wrong to me.

I suppose it’s not nice to receive a complaint like mine, but I want to clarify that the complaint is sincere and I don’t want to create controversy or bad publicity. We all make mistakes, me first (maybe I’m wrong about this complaint).

Well, I’d like to take this opportunity to wish you a happy 2026 and that everything goes very well for you.

36

Hi Jordikt,
thanks for explaining further, your point is well understood.

But know that there has not been a change in dealing with this bug report, except that a fix did not make the deadline for the 1.9.2 release. It seemed like a realistic plan at some point! Sometimes, reality bites. Of course that’s unfortunate, but that’s everyday life in software development. We have literally thousands of change requests, some of them are bugs or other kinds of issues.

As said, any issues that heavily depend on the OS can be hard or impossible to fix. This is just a word of caution and applies to all such issues. So a safe wording would be: it will be fixed in a future release, if we determine that it can be fixed. Personally, I’d love to fix it today and deliver tomorrow.

A quick test by Steve a week ago seemed that the bug does not apply anymore or could be worked around. Sometimes, issues like this get fixed along with other changes or with OS updates (and conversely, you won’t believe how much effort we have to put into fixing things just to keep the software working on new macOS version!). That’s why I asked Steve to check in the first place.

Given that you can still reproduce the issue, he tested again and could also reproduce it now. It’s on our plate just as before. I will contact you for beta testing once there is something to test. We always do that, if the user agreed.

In general, we’re not a company which appeases customers purely for customer relations. We always strive for honest and clear communication. We try to keep expectations realistic, but we also want to explain our plan. Sometimes, that does not work out, but at least we’re up-front with it. I prefer that over fuzzy communication or no communication at all.

37

Hi @jordikt ,

Sorry for forgetting the original bug report. As Florian says it os rather obscure which is probably why no one else has reported it. I had to re-dig into testing and see if I could figue a workaround but no luck. I’m guess not many people press command tab to other desktops and then press F12 afterwards.

Sorry for the confusion on my part!

Steve

38

Just to inform you that this issue was first reported on macOS Sonoma 14.7.1 and every new update of macOS hasn’t changed the issue (the issue persists along every major/minor update of macOS).

Yes, as I said you months ago, I will be glad to test betas if you need my help.

Great, thanks a lot.

There is no issue with the F12 key (I don’t press F12 after ⌘+tab).
The issue is only related to the release of the command key after switching apps in different desktops pressing ⌘+tab.
The F12 is just a key I used as example (I could have chosen any other key).
If you read carefully the first post of this thread, you can understand what the problem is and why F12 is used only to detect the problem of the command key (released in the keyboard but still pressed for BMTP).
Also in the first post you have a small project to test this issue.

No problem. But please read again the first post of this thread carefully to avoid more confussions.

39

Hi, we’ve just (silently) released an update that adds a workaround for this problem. If the Command Key Up event got missed, MT Pro will notice with the next keystroke being pressed and inject it before the incoming keystroke. That way, shortcuts and other incoming keystroke translators should work as expected.
Download Trial version here:
https://www.bome.com/products/miditranslator#downloads

Download Full version from your account:
https://www.bome.com/account/products

40

1.9.2 build 1090 has fixed the issue.

Thanks a lot for your help Florian!