hammerspoon icon indicating copy to clipboard operation
hammerspoon copied to clipboard

Incorrect window.filter callback when another instance of the application running

Open dmgerman opened this issue 3 years ago • 2 comments

I have a callback to a window filter:

theWindows:subscribe(hs.window.filter.windowCreated, callback_window_created)
theWindows:subscribe(hs.window.filter.windowDestroyed, callback_window_created)
theWindows:subscribe(hs.window.filter.windowFocused, callback_window_created)

This code works correctly except in a weird situation: two instances of the same application are running (each with at least one window).

  1. open VLC. Select a file to play. Say the file is "Good.mkv"

  2. open Another instance of VLC from the command line:

    open -n /Applications/VLC.app

  3. Select another file called "Bad.mkv".

At this point the title of the first window is "Good. mkv," the title of the second window is "Bad.mkv"

After this, irrespectively of which window is being focused or destroyed, the callback always receives the window playing "Good.mkv" of the first instance of the application.

(I think it is also the case with windowCreated, but I am not 100% sure).

dmgerman avatar Sep 02 '21 21:09 dmgerman

Just pinpointed weird behaviour I have been seeing to this same issue. I keep a global table of windows that I update upon subscription events using wf:getWindows(). I have bound alt + m to either activating or launching a minimal google chrome window for messenger.com. When no existing window is found I use this to launch the new one:

hs.execute("open -n -b com.google.Chrome --args --app=https://messenger.com/ --remote-debugging-port=9333")

As in @dmgerman's example, -n opens a new instance of the application even if one is already running. Without it MacOS just focuses an existing Chrome window if there is one.

When this new window appears I suddenly get a whole bunch of windowDestroyed events for every window of the first Chrome instance. If I click off the messenger window to a different application and then click the messenger window again I get another wave of windowCreated events for the messenger window (for some reason no windowCreated event gets fired for it when it is actually created), as well as all the previously "destroyed" first chrome instance windows.

delaneyb avatar Sep 07 '21 10:09 delaneyb

I'm seeing this issue as well... In my case, I'm running different chrome profiles with --user-data-dir so I can keep my work browsing profiles and saved logins separate from my personal.

It looks like none of the windows in the other instance show up in hs.window.filter at all.

This can be reproduced by launching chrome normally, then running a new instance of chrome like this

"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --user-data-dir=/tmp/test

and then running this in the Hammerspoon Console.

hs.inspect(hs.window.filter.new():getWindows())

alxlu avatar Dec 28 '21 00:12 alxlu