"Bring window to front" no longer works with Chrome

I have several macros that look like this:

But since updating Chrome to 131.0.6778.69, none of them work with my Chrome windows. But I definitely have Chrome windows meeting this criteria!

Any ideas on what might be going wrong here? So far the only thing I've tried is rebooting my computer.

MacOS 14.5
Chrome 131.0.6778.69
Keyboard Maestro 11.0.3

You've blurred the Google Translate tab, so I can't tell: Are you certain that the tab for Google Translate includes the word Japanese? I don't use Chrome, but when I open Google Translate in Firefox, neither of the selected languages appears in the tab name. Since the window name is that of the active tab in any given window, Keyboard Maestro won't be able to identify the window that way. But Chrome is scriptable, so there is probably a solution to be had with a few more actions.

I'm pretty sure this is a bug we ran into in Chrome with our app Witch; we filed a bug report on it:

https://issues.chromium.org/issues/378835484

(And yes, this just started with the most-recent update.)

Basically, when Chrome goes into the background, there's no information available about the frontmost window via the Accessibility API, which is how Witch works (and I assume, how Keyboard Maestro works).

The first comment there indicates they were able to reproduce it, so hopefully it'll get fixed soon. And hopefully, it's the issue that's causing the problem with Keyboard Maestro.

-rob.

3 Likes

Can he use an older version of Chrome that doesn't have this bug?

I've been using @ComplexPoint 's macro to bring Chrome tab to front with a specified string the page's title. Works beautifully. :slight_smile:

My Chrome's just updated to "Version 131.0.6778.70 (Official Build) (arm64)" -- no problem with that action here.

You've blurred the Google Translate tab, so I can't tell: Are you certain that the tab for Google Translate includes the word Japanese ?

Actually, the tab name shouldn't matter for this command -- it's the window name, which I've named with the Window > Name Window command. You can see it at the bottom of that screen grab :slight_smile:

Are you on MacOS or PC?

Oh, interesting, is that a Chrome feature?

Yes, it is

Mac (note the arm64 processor, and the fact that KM is Mac-only software :wink: ).

That's what's breaking it, compared to my test. The %FrontBrowserWindowName% returns the renamed window name but the "Bring Window to the Front" action requires the orginal name.

While you wait to it to be fixed (or for someone to come up with a cunning JavaScript solution), you could replace your current actions with an "Execute AppleScript" action along the lines of

tell application "Google Chrome"
	set index of item 1 of (every window whose title contains "Rubbish") to 1
end tell

...replacing "Rubbish" with the name of your window.

Or you could stop renaming windows :wink:

1 Like

This is actually a second bug, which has already been fixed and is hopefully on its way to Chrome:

https://issues.chromium.org/issues/374947846

Until recently, the name was exported as the window title for other apps to see; they broke that, but hopefully the fix won't take long to reach Chrome.

-rob.

1 Like

Oh dear...

Well, at least while OP waits for that to be fixed (and what will they break in the process?) the workarounds of either popping the window with AS or simply not renaming the window in the first place work with the current version of Chrome.

Unfortunately, Chrome has a history of having a different Window menu name, and Accessibility reported window name so there is no guarantee they are the same.

1 Like

I will say this worked out for me! There's a very slight but still perceptible delay before the window shows up -- perils of Applescript, I suppose. But this will keep me alive until Chrome (hopefully) fixes this. Thanks much!