BTT crashes on 2nd use of gesture with menu of multiple actions

Describe the bug
I have several actions configured for the same custom tap sequence. When I perform that gesture, a menu appears showing those actions.

In recent alpha versions of BTT, when I perform the gesture a second time, BTT crashes.

Affected input device:
MacBook Pro trackpad.

Device information:

  • Type of Mac: 2013 retina MacBook Pro 15.4″
  • macOS version: 10.14.6
  • BetterTouchTool version: 3.281 through 3.286 (currently the latest)

Additional information (e.g. StackTraces, related issues, screenshots, workarounds, etc.):
In older versions of BTT up through and including 3.280, the gesture works as expected without crashing.

Should be fixed in 3.287 (and while fixing I added keyboard support to it, so now the selection can be moved with arrow keys and triggered with return)

Well…BTT no longer crashes, but the menu doesn’t work right either. I’m on v3.290 now, and here’s what I see:

When I activate the gesture (which is custom 4-finger tap sequence [3, 2, 1, 4]), the menu pops, but about half the time it immediately disappears. It seems that if I hold all 4 fingers down after the gesture, the menu stays, but if I remove some of them quickly it vanishes.

Also, there is a gray outline around the first menu item which does not move, and there is a dark background behind the last menu item which does move with the mouse but it starts out on the bottom item even though the cursor isn’t there.

The keyboard navigation works great, though I would like to be able to select an option with the spacebar (just like I can in regular Mac OS menus).

Edit: I think it’s triggering tip-taps which I also have configured, and that’s why the menu disappears. That never happened previously. When I disable my tip-tap gestures the menu stays visible. Of course, I don’t want to disable them because I use those gestures, so it’s still a problem.

Edit 2: After downgrading to v3.280, I see that the extra tip-tap are happening, but they don’t make the menu disappear like in 3.290.

Hu that's weird, what kind of tip taps?

2-finger fixed, then…

Tap left sends ⌘-[ (navigate back)
Tap right sends ⌘-] (navigate forward)
Tap middle sends ⌘-R (refresh page)

I also have some 3-finger fixed tip-taps, but they aren’t being triggered here.

And what kind of tap sequence to you use? (e.g. 4 3 2 1)

I added a quick fix that cancels any ongoing two finger fixed tip tap as soon as four finger have touched the trackpad. Will be online in a 5 minutes, maybe it helps

1 Like

Well, the menu now stays visible in 3.291, but unfortunately the items in the menu don’t work.

The actions I have in the menu are:

Send ⌘-Q (quit)
Send ⌘-W (close window)
Send ⌘⇧-W (close all)
Send ⌘⇧-T (reopen last closed)

None of them have any effect now.

Edit: Correction, none of them have any effect in applications other than BTT. They do work when BTT is the foreground application.

Edit 2: Same result in 3.292, the menu items are non-functional outside of the BTT application itself.

Ah yes because the window was now eating the keyboard input. Fixed in 3.293

Okay, the actions now work, however when the menu is up and I press esc to close it, the currently-highlighted menu item is activated when I release the escape key. It seems that modifier keys do the same thing: if I press and release any of (cmd / opt / ctrl / shift) then the highlighted item is activated. And fn does the same thing on key-down.

This unexpected behavior is especially problematic because, as I mentioned earlier, the bottom-most menu item is initially highlighted when I bring up the menu, even though the mouse cursor is not near it. Thus if I simply bring up the menu then hit esc to dismiss it, the last menu item is activated. Here’s a screenshot of what it looks like when I first perform the gesture to bring up the menu, without moving the cursor:

BTT popup menu

The above is in BTT 3.295.

For comparison, here’s the same thing under BTT 3.280:

BTT popup menu 3.280

1 Like

True, I have disabled the unexpected key behavior for this menu in 3.296!

1 Like

Great! It’s now usable once again!

I still find it weird that the last item in the menu is initially highlighted—when I mouse over the menu then move the cursor away, none of the items are highlighted. So I would expect that initially, since the mouse is not over the menu, none should be highlighted.

Also, I can’t figure out the purpose of the outline around the first menu item. It doesn’t move with either tab or the arrow keys, and it is not triggered by either return or the spacebar. It seems unnecessary.

mh I don’t have any outline here, maybe because I’m on 10.15. I’ll have a look at my other machine.

I like the selection when triggering the menu using a keyboard shortcut because it immediately indicates the selection can be moved.

I think it’s better to match the standard behavior of menus, including context menus, in OS X.

If you click a menubar menu (eg. File, Edit, etc.) then none of the items are selected at first, but you can still use the arrow keys.

Similarly if you right-click (or ctrl-click), a context menu pops up and no items are selected, but you can still use the arrow keys.

That’s how all menus work in OS X, it is the standard system behavior, and I think doing anything else would be unexpected.

On the one hand I agree, on the other handI have seen so many people who just didn't know they could use the arrow keys or even type select in standard macOS context menus.

In the menubar the topmost item is highlighted, thus indicating a "selection". Only in context menus no selection is there at the beginning.

I would say that lack of knowledge about standard OS behaviors is outside the scope of what BTT should try to solve.

The topmost item is not selected in a regular menu. If you are referring to the name of the menu itself, that is a selection within the menubar, not within its own menu.

Notably, after clicking the name of a menu, moving the selection with the up and down arrows does not deselect the name of the menu itself (whereas the side arrows do change which menu is selected).

And repeatedly hitting the up arrow will never move the selection “up out of the menu”—it stops at the topmost item within the menu.

Yes, that is the best analogy. The BTT menu is essentially a context menu—the context being “What BTT trigger was used to bring up this menu.”

It should look and act like a context menu, to best match user expectations and function seemlessly like a part of the OS.

I don't need to solve the OS behavior, but I can always make the BTT behavior better :slight_smile: (Gestures, Window Snapping, Touch Bar customization etc. are also not part of the standard behavior of macOS still they are very popular :-))

For me the menubar title belongs to the menu (maybe because that's how it's structured programatically, just like submenus in a context menu).

So while I don't (fully) agree that the standard context menu behavior of macOS is good, I have disabled the initial selection for now - but I'm looking for other options to indicate the keyboard support.

Hooray!

There are still a couple oddities I notice:

When I bring up the menu while a Google Chrome window is active, focus shifts away from that window. Specifically, I observe that the titlebar of the Chrome window fades to lighter gray. Focus returns when I close the menu. This does not occur when another program besides Chrome is active, and it does not affect functionality, it’s just a bit strange.

Also, when the menu is active, hitting esc only closes the menu if a menu item is highlighted. If no item is highlighted, then esc has no effect.

Another oddity:

Hovering the mouse over one of the menu items makes a tooltip appear, which just shows the name of the menu item under the cursor. This does not occur for other menus, neither from the menubar nor context menus. Here’s a screenshot of the redundant tooltip on the BTT menu:

BTT popup menu hover.280