Hammerspoon: hs.window.orderedWindows() broken

[drogers141]

Installed version Version 0.9.44 (0.9.44)
and now hs.window.orderedWindows() is broken. For example:

hs.window.orderedWindows()
...oon.app/Contents/Resources/extensions/hs/window/init.lua:125: attempt to call a nil value (method 'visibleWindows')
stack traceback:
...oon.app/Contents/Resources/extensions/hs/window/init.lua:125: in function 'hs.window.internal.visibleWindows'
...oon.app/Contents/Resources/extensions/hs/window/init.lua:141: in function 'hs.window.internal.orderedWindows'
(...tail calls...)
[C]: in function 'xpcall'
...app/Contents/Resources/extensions/hs/_coresetup/init.lua:250: in function <...app/Contents/Resources/extensions/hs/_coresetup/init.lua:244>

[bezhermoso]

Having this issue as well. As far as I can tell, looks like app:allWindows() is causing the error if the app is loginwindow.

(EDIT: strike that)

[bezhermoso]

Can confirm that the problem does not exist in version 0.9.43

[cmsj]

This rather suggests that there's an application object that's missing the visibleWindows() method. Could you run this in the Hammerspoon Console and see what it prints please?

hs.fnutils.each(hs.application.runningApplications(), function(app) 
  if not app.visibleWindows then 
    print(app) 
  end 
end)

[bezhermoso]

@cmsj Nothing is printed.

However it looks like the problem is no longer happening to me. Perhaps there is a particular application(s) that, when running, causes this bug?

Will keep an eye out. I'll keep the latest release running and will post the result of that debug script when I encounter the bug again.

[bezhermoso]

@cmsj

I am now able to replicate it at will.

For reference, here is the contents of my ~/.hammerspoon/init.lua:

local window = require "hs.window"
local screen = require "hs.screen"
local hotkey = require "hs.hotkey"
local fnutils = require "hs.fnutils"

function windowInScreen(screen, win)
  return win:screen() == screen
end

function focusNextScreen()
  local next = window.focusedWindow():screen():next()
  windows = fnutils.filter(window.orderedWindows(), fnutils.partial(windowInScreen, next))
  if #windows > 0 then
    windows[1]:focus()
  else
    window.desktop():focus()
  end
end

function focusPreviousScreen()
  local previous = window.focusedWindow():screen():previous()
  windows = fnutils.filter(window.orderedWindows(), fnutils.partial(windowInScreen, previous))
  if #windows > 0 then
    windows[1]:focus()
  else
    window.desktop():focus()
  end
end

hotkey.bind({"alt", "ctrl"}, "L", focusNextScreen)
hotkey.bind({"alt", "ctrl"}, "H", focusPreviousScreen)

function reloadConfig(files)
  doReload = false
  for _, file in pairs(files) do
    if file:sub(-4) == ".lua" then
      doReload = true
    end
  end
  if doReload then
    hs.reload()
  end
end


hs.pathwatcher.new(os.getenv("HOME") .. "/.hammerspoon/", reloadConfig):start()
hs.notify.new({title="Hammersppon", informativeText="Configuration reloaded!"}):send()

The error occurs when I invoke the focusNextScreen or focusPreviousScreen via the hotkeys.

However, as soon as I execute your debug script, the error never occurs again, until I reload the configuration.

I discovered that pre-loading hs.application by requiring it at the top of my config file solves the error.

[emosesSfdc]

I see a similar problem, but only when I interact with IntelliJ. For some reason, it appears that, if IntelliJ is active, hs.window.focusedWindow() is nil, and also seems to be a problem when IntelliJ is selected and calls hs.window.frontmostWindow(). I had functions which worked in older Hammerspoon versions which no longer work, for example:

hs.hints.showTitleThresh = 100

hs.hotkey.bind(mod1shift, ";", function()
                  hs.hints.windowHints(hs.window.focusedWindow():application():allWindows(), nil, true)
end)


hs.hotkey.bind(mod1, "d", function()
                  hs.window.focusedWindow():moveOneScreenEast()
end)

I know from previous experience that IntelliJ does some weird stuff with its windows, see my earlier Issue #587 (and associated PR), I'm sure it's related.

[YA2O]

+1 on problem with nil value when running with IntelliJ.

[cmsj]

@emosesSfdc @YA2O I think the IntelliJ issue is separate from this - it's an app that doesn't implement OS X's accessibility APIs, which means we can't interact with it properly :/

[lowne]

@cmsj there's a circular dependency between window and application; the only solution I can think of (short of always preloading application in e.g. _coresetup) involves the sort of package.loaded inject trick that I had originally used for window's submodules; I think it's quite hacky in principle, but maybe acceptable as a one-off for the weird application/window couple? If so, I can put together a PR.

[cmsj]

@lowne yeah I think we have to do that for the weirdness that is application/window. Thanks!

[emosesSfdc]

@cmsj in previous versions of Hammerspoon, focusedWindow() was non-nil for IntelliJ. I know it does things differently and it's possible that Hammerspoon's full functionality won't work with IntelliJ, but this is definitely a regression.

[lowne]

git blame shows that window_focusedwindow hasn't changed since 2014, and I don't see how the recent LuaSkin changes could affect it - then again I know nothing about the C side.

[SergioBenitez]

Just ran into this issue myself. Adding require "hs.application" to my init.lua file prevents the issue from occurring.