Borders sometimes don't draw (or disappear) on some windows

[sim590]

Output of awesome --version:

awesome v4.2-257-g59aa4ac7 (Human after all)
 • Compiled against Lua 5.1.4 (running with LuaJIT 2.1.0-beta3)
 • D-Bus support: ✔
 • execinfo support: ✔
 • xcb-randr version: 1.5
 • LGI version: 0.9.2

How to reproduce the issue:

Thanks to @h1nk, one can reproduce this issue following this procedure:

1. Using the following theme settings on v4.3:

beautiful.border_width = dpi(10)
beautiful.border_normal = '#FF0000'
beautiful.border_focus = '#00FF00'
beautiful.maximized_hide_border = false
beautiful.fullscreen_hide_border = false

2. Opening an instance of xfce4-terminal or firefox and maximizing it 3. Running a killall -HUP awesome 4. Un-maximizing the client window (xfce4-terminal, firefox, etc.)

Actual result:

Here we can see that the window has no drawn borders (no redish color) even though the window is focused:

When selecting the other window on the left, we clearly see the redish colored border:

Expected result:

Borders are always drawn when window is focused.

Workaround

Restart awesome and it fixes it (until it breaks again).

[psychon]

I'm not quite completely sure what I am seeing here [edit: on the screenshots], but could you create a keybinding for function() naughty.notify{ text = client.focus.border_color } end and check if this reports the correct border color? Also, could you run awesome with --no-argb and see if this makes the issue go away?

[sim590]

I'm waiting for the issue to appear again. I have seen this issue a couple of times in the past, so it should trigger again sometime soon.

[sim590]

If that bug is somehow related to luaJIT, it won't trigger anymore due to it as I have switched to plain lua in order to go around #2200. I'm just pointing this out in case someone can confirm.

[psychon]

I doubt a lot that the Lua implementation has something to do with disappearing borders.

Do you have anything more than just client.connect_signal("focus", function(c) c.border_color = "#e66e7f" end) in your config about border? On a second look at your screenshot, there is no border at all. If I understand the screenshot directly, there are two clients next to each other, but there is just a single black pixel between them. So either they overlap (shouldn't happen) or one of them has border_width = 0.

[sim590]

On a second look at your screenshot, there is no border at all. If I understand the screenshot directly, there are two clients next to each other, but there is just a single black pixel between them.

From rules.lua, I have:

properties = { border_width = beautiful.border_width,
    ...
}

From my theme, I have border_width = 1, so there is indeed one pixel for drawing the border, but from my understanding, there should be a pixel for each of the clients, no? Also, I haven't seen the bug in a while. In fact, here's a screenshot in the same layout as but where we clearly see the border:

If I move my cursor to the other windows, I see the border around the other window too. It's just that sometimes there are single windows which won't have any border when focused.

[sim590]

@psychon The issue just appeared again. I made a video to illustrate it even more.

I have run the following code with sleep 3 && bash client_border_color.sh:

#!/usr/bin/env bash
awesome-client "local naughty = require('naughty'); naughty.notify{ text = client.focus.border_color }"

The sleep command was to let me place the mouse over the faulty client before the code runs. The result is the same as healthy windows, i.e. : #e66e7f which is the color I want to see.

[actionless]

do you see anything in ~/.xsession-errors or wherever your awesome is writing stderr?

[sim590]

I see a lot of the following recurrently:

2018-03-20 13:16:37 E: awesome: Error during a protected call: /usr/share/awesome/lib/gears/protected_call.lua:31: attempt to call upvalue 'func' (a number value)
stack traceback:
        /usr/share/awesome/lib/gears/protected_call.lua:31: in function </usr/share/awesome/lib/gears/protected_call.lua:30>
        [C]: in function 'xpcall'
        /usr/share/awesome/lib/gears/protected_call.lua:30: in function </usr/share/awesome/lib/gears/protected_call.lua:28>
        (tail call): ?
        /usr/share/awesome/lib/gears/timer.lua:198: in function 'func'
        /usr/share/awesome/lib/gears/object.lua:123: in function </usr/share/awesome/lib/gears/object.lua:120>
        (tail call): ?
        [C]: in function 'xpcall'
        /usr/share/awesome/lib/gears/protected_call.lua:30: in function </usr/share/awesome/lib/gears/protected_call.lua:28>
        (tail call): ?
        /usr/share/awesome/lib/gears/timer.lua:92: in function </usr/share/awesome/lib/gears/timer.lua:91>

This also:

2018-03-20 15:37:46 W: awesome: a_glib_poll:431: Last main loop iteration took 0.139200 seconds! Increasing limit for this warning to that value.

The following happenned once today:

2018-03-20 16:20:41 E: awesome: a_xcb_io_cb:396: X server connection broke (error 1)

I get some warnings like the following:

2018-03-20 17:59:18 W: awesome: awful: function set is deprecated. Use c.floating = true instead of awful.client.floating.set.
stack traceback:
        /usr/share/awesome/lib/gears/debug.lua:95: in function 'deprecate'
        /usr/share/awesome/lib/awful/client.lua:562: in function 'set'
        /home/simon/.config/awesome/rc/keys.lua:76: in function 'press'
        /usr/share/awesome/lib/awful/key.lua:91: in function </usr/share/awesome/lib/awful/key.lua:91>
2018-03-20 17:59:18 W: awesome: awful: function moveresize is deprecated. Use c:relative_move(x, y, w, h) instead of awful.client.moveresize.
stack traceback:
        /usr/share/awesome/lib/gears/debug.lua:95: in function 'deprecate'
        /usr/share/awesome/lib/awful/client.lua:320: in function 'moveresize'
        /home/simon/.config/awesome/rc/keys.lua:77: in function 'press'
        /usr/share/awesome/lib/awful/key.lua:91: in function </usr/share/awesome/lib/awful/key.lua:91>

This is due to one of my mappings.

Other than this, nothing is written to the file when I hover the mouse on the faulty client.

[actionless]

but nothing is being written if you tail -f the log and performing the steps to reproduce the issue?

[psychon]

Did you yet try running awesome with --no-argb? https://github.com/awesomeWM/awesome/issues/2195#issuecomment-366620109

I cannot play the video currently (missing codec), but if awesome things the border color is what it should be, then I would tend to blame the X11 server / your video driver. --no-argb (not trying to have working transparency) usually works around those issues.

[sim590]

@actionless

but nothing is being written if you tail -f the log and performing the steps to reproduce the issue?

As I said on the last line of my comment.

@psychon

Did you yet try running awesome with --no-argb? #2195 (comment)

I have not tried it yet. I will try it, but since the bug doesn't occur in a deterministic manner AFAICT or from my perspective anyway, I can't say for sure if that will fix it.

[actionless]

it wasn't clear if those messages are written when you hover or you just found them in your log but unrelated

[sim590]

I have tested --no-argb and it seems like it lets avoiding the issue. I have been testing it for a week now and I have not noticed borders not drawing.

[rkfg]

I also have this issue but I already run awesome with --no-argb so that might not be the solution.

An easy way to trigger this for me is to do this with any window: Go fullscreen Maximize Unmaximize Unfullscreen again. My modkey is Left Alt so all I need to do is press Alt+F, Alt+M, Alt+M, Alt+F. Then the window loses its border until I restart Awesome.

awesome v4.3 (Too long)
 • Compiled against Lua 5.3.3 (running with Lua 5.3)
 • D-Bus support: ✔
 • execinfo support: ✔
 • xcb-randr version: 1.6
 • LGI version: 0.9.2

Running on Debian testing/amd64. I made sure it's not my bug by running with the default config and theme Zenburn that has visible borders. It's reproducible (using Winkey as the modkey).

[sim590]

I have just add the issue again with --no-argb on. So that's confirmed: --no-argb doesn't suffice to avoid the bug.

[h1nk]

I've also noticed this issue for a while but didn't bother trying to solve it. I have it happen commonly after reload/restarting awesome and then moving some window clients from the maximized state.

[h1nk]

I just tried with --no-argb and the problem is still happening. I'm able to reproduce the issue by doing the following:

1. Using the following theme settings on v4.3:

beautiful.border_width = dpi(10)
beautiful.border_normal = '#FF0000'
beautiful.border_focus = '#00FF00'
beautiful.maximized_hide_border = false
beautiful.fullscreen_hide_border = false

2. Opening an instance of xfce4-terminal or firefox and maximizing it 3. Running a killall -HUP awesome 4. Un-maximizing the client window (xfce4-terminal, firefox, etc.)

[sim590]

@h1nk YES! I can reproduce also using quteborwser. Really, any window suffices I think. You have to restart awesome while some windows are maximized. Then after restarting, unmaximizing the window triggers the bug !! Yes.

I have updated OP to quote your procedure for reproducing the bug.

[h1nk]

@actionless & @psychon, since this can be reproduced when reloading awesomeWM using SIGHUP perhaps it's tied to the reload & maximize/minimize logic?

[Elv13]

can you try git-master? I made some changes to the border code, it might be better (or worst, or nothing changed).

edit: also remove the section in rc.lua which set the border, the fallback code will kick-in.

[h1nk]

@Elv13 I installed git master and nuked my rc.lua to use the WM defaults but it still has the same issue so it doesn't seem to be fixed.

[Selion05]

I just had a similar issue... opened firefox and it had no boarder (it used the boarder space for the window) . Normally the active window has a red boarder. Restarting awesome fixed it though

[btstream]

Confirmed on chrome and nvim-qt with latest git master version

[pranabekka]

I was fixing( issue #1595 with Inkscape when I noticed the issue, which makes me think the issue has to do with the maximising logic, as @h1nk suggested.

With the fix, it launches with no border at all, whether maximised or not.

Without the fix, it launches with a border, but loses it when I un-maximise it. The border doesn't return on maximising again.

If I launch Inskcape with the fix applied, then remove the fix and reload awesome, then the border reappears and stays whether it is maximised or minimised.

If I launch Inkscape without the fix, then add the fix and reload awesome, then it loses its border again.

I'll let you know if this happens again, or if it's a one-off.

Awesome version:

awesome v4.3 (Too long)
 • Compiled against Lua 5.3.3 (running with Lua 5.3)
 • D-Bus support: ✔
 • execinfo support: ✔
 • xcb-randr version: 1.6
 • LGI version: 0.9.2

The fix (from blueyed's comment, adding the following to the default rule for all clients):

callback = function(c)
  c.maximized, c.maximized_vertical, c.maximized_horizontal = false, false, false
end,

[8Dion8]

Has this issue been fixed at all? Still happening on

awesome v4.3 (Too long)
 • Compiled against Lua 5.3.6 (running with Lua 5.3)
 • D-Bus support: ✔
 • execinfo support: ✔
 • xcb-randr version: 1.6
 • LGI version: 0.9.2

[actionless]

first of all double-check if you still can reproduce this using awesomewm built from the latest git commit

[RaviRahar]

Still reproducible with :

I just tried with --no-argb and the problem is still happening. I'm able to reproduce the issue by doing the following:

1. Using the following theme settings on v4.3:

beautiful.border_width = dpi(10)
beautiful.border_normal = '#FF0000'
beautiful.border_focus = '#00FF00'
beautiful.maximized_hide_border = false
beautiful.fullscreen_hide_border = false

2. Opening an instance of xfce4-terminal or firefox and maximizing it 3. Running a killall -HUP awesome 4. Un-maximizing the client window (xfce4-terminal, firefox, etc.)

Using:

awesome v4.3-1539-gb16f62862 (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 • Transparency enabled: yes • Custom search paths: no

[rkfg]

I just fixed it in a very dumb way:

    awful.key({ modkey, }, "f", function(c)
        c.fullscreen = not c.fullscreen
        if not c.fullscreen then
            c.border_width = beautiful.border_width
        end
        c:raise()
    end, { group = "client" }),
    awful.key({ modkey, }, "m", function(c)
        c.maximized = not c.maximized
        if c.maximized then
            c.border_width = beautiful.border_width
        end
        c:raise()
    end, { group = "client" })

And that's it. It will clash with your border rules in awful though.