Closing Chrome tab doesn't work consistently on 2nd display

I have a macro that grabs ⌘W when a web browser is the front application and checks the title of the tab so that I can’t accidentally close certain sites like gmail. This works fine when Chrome is on the primary display (iMac) but it is not consistent when Chrome is on the 2nd display.

The macro runs and completes without failures but the actual close action is not immediate. I can run the macro and the tab won’t close until I click at the top of the Chrome window in the tab bar area or in the menu bar. I can even switch to another app then come back a few minutes later and when I click up top, then the close action happens.

I’ve changed the macro many times to close the tab different ways, like using “Select ‘Close tab’ in the Menu ‘File’ in the Front Application”, Simulating the keystroke ⌘W, and running an Applescript that uses System Events to close the tab.

Has anyone experienced anything like this? I’m guessing this is a Chrome or OSX bug and not a problem with KM but hoping someone knows a fix.

Thanks

Please post your macro (image an file) so we can be of more help.
I have multiple monitors and various macros that close Chrome tabs/windows, and have never had an issue.

I've done some testing this evening and discovered that it isn't just Chrome but actually is a problem with KM. I've consistently reproduced it using multiple macros and various applications.

  • Macro execute an action to select a menu item
  • Active application is on 2nd display
  • Primary display has an app in Full Screen mode (tested with iTunes, Fusion)

Below is an example using KM itself. This macro is in a group that is only active for KM.
It makes ⌘E call the menu to start/stop edit mode.
With the KM window on the 2nd display and iTunes on the primary display in Full Screen mode, pressing ⌘E does not switch edit modes until I click on the menu bar.

For testing, I changed the Chrome macro from using the "Close Tab" Select Menu action to use an Applescript that tells Chrome to close the tab. This new method worked 100% of the time. During the testing, I had moved the KM window over to the 2nd display and discovered it failed in the same way.

Applescript to close the Chrome tab
set matchTitle to "Bingham.co Mail"
tell application "Google Chrome"
	set aTab to active tab of window 1
	set aTitle to title of aTab
	if aTitle does not contain matchTitle then
		tell aTab to close
	end if
end tell

I've tested the macros with the debugger, making sounds as it runs each step, and creating log entries. It runs fully without errors but the actual menu action doesn't happen until later.

I'm guessing that because the primary display is in full screen mode, it doesn't have an active menu bar. When KM calls to select the menu item, the system puts the request in a queue waiting for that menu item to be available. I can continue using the app and even switch between apps. If I'm in the app with that menu and I click on the menu bar, the system sees the menu item is now available and executes the action.

P.S. Peter, could you please make the ⌘E shortcut start and stop editing mode? I can't do it in the system Keyboard Shortcuts because the menu item changes names and it will only allow me to set ⌘E to a single item. This is why I've created this macro.

Thanks

Edit Macro Image

I can confirm this anomalous behavior, running Keyboard Maestro 7.3.1 (7.3.1) on macOS 10.11.6.

  • Put Evernote to full screen on primary screen 1
  • Selected/Activated KM on screen 2
  • KM macros that access the KM menu, or cause a conflict palette do not work.

I very rarely use full screen mode, so I had not noticed this behavior.

@peternlewis, I think this is a bug. Can you please confirm?

Steps to reproduce

  1. Put any app to full screen on the primary screen 1
  2. Activate an app on screen 2
  3. Trigger a macro that uses the menu of the app on screen 2
  4. Observe that the macro fails -- does not run.

It does look to be a bug, but I don’t think it’s a bug in Keyboard Maestro. It’s unchanged in 10.12.6.

In my test, if I selected a menu, it appeared to do nothing and no error is reported, so Keyboard Maestro is happy that it has found and selected the menu. And then if I click in the menu bar, the selected menu is processed. So it looks like the system has received the menu selection and then it just holds on to it until you click the menu bar.