setting client.screen doesn't properly change client.active

[Pikabyte]

Output of awesome --version:

awesome v4.3-1588-g11f5eff3 (Too long) • Compiled against Lua 5.4.4 (running with 0.9.2) • API level: 4 • D-Bus support: yes • xcb-errors support: no • execinfo support: yes • xcb-randr version: 1.6 • LGI version: /usr/share/lua/5.4/lgi/version.lua • Transparency enabled: yes • Custom search paths: no

How to reproduce the issue: Simply change a client to a new screen, and look at if the client is active before and afterwords. (Assume "1" is a different screen in the code)

        print("before: ", c.active)
        c.screen=1
        print("after: ", c.active)

Actual result:

You'll notice that the output suggests client says it is active, but will actually not be.

before:     true
after:     true

Expected result:

The expected result should be that the client should not be active. This expectation comes from the code for client:move_to_screen, where it seems to assume it works like this. It sends an activate request which does nothing because the client already thinks it's active.

function client.object.move_to_screen(self, s)
    if self then
        local sc = capi.screen.count()
        if not s then
            s = self.screen.index + 1
        end
        if type(s) == "number" then
            if s > sc then s = 1 elseif s < 1 then s = sc end
        end
        s = get_screen(s)
        if get_screen(self.screen) ~= s then
            local sel_is_focused = self.active
            self.screen = s
            screen.focus(s)

            if sel_is_focused then
                self:emit_signal("request::activate", "client.movetoscreen",
                                {raise=true})
            end
        end
    end
end

[Pikabyte]

I could make a pull request to simply change this function to make it work as it should, but I'm not sure if there is some other underlying issue that should be fixed instead, so I figured I should make this first.

[Pikabyte]

Okay, so after some testing. It seems that the problem might actually be with self:emit_signal. It seems to be that the client does actually unfocus, but that the signal is somehow only emitted before that, when it should be emitted after. Is there a way to emit a signal on the next event loop rather than on the current one?

before:     true    focused:     window/client(~): 0x55fdeceecb48
after:     true    focused:     window/client(~): 0x55fdeceecb48
unfocus is now    nil    stack traceback:
    /home/darth/.config/awesome/config/bindings/clientkeys.lua:48: in function </home/darth/.config/awesome/config/bindings/clientkeys.lua:48>
    [C]: in method 'tags'
    /usr/share/awesome/lib/awful/client.lua:1009: in method 'to_selected_tags'
    /usr/share/awesome/lib/awful/permissions/init.lua:323: in function 'awful.permissions.tag'
    [C]: in method 'emit_signal'
    /usr/share/awesome/lib/awful/tag.lua:2088: in function </usr/share/awesome/lib/awful/tag.lua:2074>
    [C]: in function 'xpcall'
    /usr/share/awesome/lib/gears/protected_call.lua:41: in function </usr/share/awesome/lib/gears/protected_call.lua:40>
    (...tail calls...)
    /usr/share/awesome/lib/gears/timer.lua:280: in function 'gears.timer.run_delayed_calls_now'

[unai-ndz]

Haven't really looked too much into the bug in the OP but:

Emit a signal on the next event loop

Take a look at gears.timer.delayed_call

[sclu1034]

Haven't really looked too much into the bug in the OP but:

Emit a signal on the next event loop

Take a look at gears.timer.delayed_call

You might want to take another look at its documentation yourself. It does not do what Pikabyte is asking for.