Clicking on ‘Cursor Tab’, hiding Cursor (the application, by say clicking a different application in the MacOS dock), then bringing Cursor back into focus causes the ‘Cursor Tab’ menu to open, despite no hover interaction / click action having just taken place.
I don’t think the intention is that it’s only accessible via a hover interaction, given that ‘un-disabling’ occurs by clicking the button. Clicking then toggling focus of the app does cause the menu to appear after the application receives focus again. Every other button in that footer is clickable. If this isn’t a bug, what’s the benefit of forcing a hover interaction over having the button be clickable?
Clicking the buttons doesn’t disable the tab, hovering the mouse cursor brings up a popup with options, and this behavior occurs not only with the Cursor Tab. For example, if you hover over the TypeScript button, a popup with additional options appears. So, we’re not breaking any logic here.
I understand that the other buttons have hover functionality, the hover functionality works fine.
I’m trying to convey that every other button in the footer is clickable, the Cursor Tab button is also clickable, but only when it’s in the disabled state. When it’s in the non-disabled state, it seemingly doesn’t do anything on click:
If you do click it, then focus a different application, then come back to Cursor, the menu appears.
If that is the intended behaviour I’m finding it quite confusing. I think buttons should be clickable.
To take a different approach, if you use a keyboard navigation, you can navigate around the rest of the buttons, into and out of menus, etc, but the Cursor Tab menu isn’t enterable via keyboard navigation in either state. You can select ‘Cursor Tab’ when it’s disabled and hit space, but that only enables it again, it’s not possible to get into the menu itself. When it’s enabled, hitting space (just like clicking) does nothing.
