awful.placement.no_offscreen will place window titlebar offscreen

[tleydxdy]

Example:

[psychon]

Uhm... could you provide the necessary config snippet for this? Looking at awful.rules (and assuming you are using awful.rules) this Should Not Happen (tm). This handles titlebars_enabled before placement. Also, a client's :geometry() always includes its titlebar.

So basically: I cannot really reproduce this.

[tleydxdy]

awful.rules.rules = {
    -- All clients will match this rule.
    { rule = { },
      properties = { border_width = beautiful.border_width,
                     border_color = beautiful.border_normal,
                     focus = awful.client.focus.filter,
                     raise = true,
                     keys = clientkeys,
                     buttons = clientbuttons,
                     screen = awful.screen.preferred,
                     placement = awful.placement.no_overlap+awful.placement.no_offscreen,
		     size_hints_honor = false
     }
    },

    -- Floating clients.
    { rule_any = {
        instance = {
          "DTA",  -- Firefox addon DownThemAll.
          "copyq",  -- Includes session name in class.
        },
        class = {
          "Arandr",
          "Gpick",
          "Kruler",
          "MessageWin",  -- kalarm.
          "Sxiv",
          "Wpa_gui",
          "pinentry",
          "veromix",
          "xtightvncviewer"},

        name = {
          "Event Tester",  -- xev.
        },
        role = {
          "AlarmWindow",  -- Thunderbird's calendar.
          "pop-up",       -- e.g. Google Chrome's (detached) Developer Tools.
        }
      }, properties = { floating = true }},

    -- Add titlebars to normal clients and dialogs
    { rule_any = {type = { "normal", "dialog" }
      }, properties = { titlebars_enabled = true }
    },
}

[psychon]

Hm. I still have no idea. Does this happen with all programs or just some specific ones? If so, could you run xprop in a terminal, click on the window causing this and show the output of xprop? (I'd guess that this could be window-gravity-related...).
@Elv13 Any other ideas?

[tleydxdy]

awful.client.property.floating(CARDINAL) = 1
_NET_WM_DESKTOP(CARDINAL) = 3
_NET_FRAME_EXTENTS(CARDINAL) = 1, 1, 21, 1
WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x0
_NET_WM_USER_TIME(CARDINAL) = 89774301
_NET_WM_ICON(CARDINAL) = 
XdndAware(ATOM) = BITMAP
_NET_WM_NAME(UTF8_STRING) = "Genymotion for personal use - Google Nexus 5X - 7.0.0 - API 24 - 1080x1920 (1080x1920, 420dpi) - 192.168.56.101"
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x1, 0xe, 0x0, 0x0
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_XEMBED_INFO(_XEMBED_INFO) = 0x0, 0x1
WM_CLIENT_LEADER(WINDOW): window id # 0x3c00002
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: True
		Initial state is Normal State.
_NET_WM_PID(CARDINAL) = 19650
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 62914590
WM_CLASS(STRING) = "player", "Genymotion Player"
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		user specified location: 1, 21
		user specified size: 526 by 848
		window gravity: Static

this is what it looks like

seems like it happens when I set a tiled window into floating.
It does happen for many windows, however, if I launch these window in float layout they works fine.

[psychon]

WM_NORMAL_HINTS(WM_SIZE_HINTS):
		user specified location: 1, 21
		user specified size: 526 by 848
		window gravity: Static

Is this specific to windows with static gravity? Also, is the window actually at the position it asks to be? (xwininfo can tell you the exact position of a window, the "Absolute upper-left" is the interesting information here)

[tleydxdy]

  Absolute upper-left X:  0
  Absolute upper-left Y:  0
  Relative upper-left X:  0
  Relative upper-left Y:  20
  Width: 160
  Height: 160
  Depth: 24
  Visual: 0xd5
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x3a00013 (not installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +0+0  -3360+0  -3360-920  +0-920
  -geometry 160x160+0+0

I just mesureed the window size with screenshot tool, seem like the geometry didn't include the titlebar, the visiable part is 160x160.

[psychon]

Hm, okay. So you are on a tiled layout, you start something that opens a window, then you make the window floating and the window ends up so that the titlebar is outside of the screen (the window itself (without titlebar) ends up at position 0x0).

I just tested that with urxvt and the titlebar ended up at 0x0, so not outside of the screen.

Does this only happen for programs for which xprop WM_NORMAL_HINTS reports window gravity: Static? Your example above has this, so I wonder if this is the key to reproducing this, or if this is just a coincidence.

[tleydxdy]

possible, here is another window that does this, but I'm able to stop this behavior by maximizing it before I change it to float because then it wont move when it was changed to float

WM_NAME(COMPOUND_TEXT) = "虹色の世界 - 相良心"
_NET_WM_NAME(UTF8_STRING) = "虹色の世界 - 相良心 — Cloud Music"
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x1, 0x0, 0x0, 0x0
_NET_WM_WINDOW_TYPE(ATOM) = _KDE_NET_WM_WINDOW_TYPE_OVERRIDE, _NET_WM_WINDOW_TYPE_NORMAL
_XEMBED_INFO(_XEMBED_INFO) = 0x0, 0x1
WM_CLIENT_LEADER(WINDOW): window id # 0x2400007
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: True
		Initial state is Normal State.
_NET_WM_PID(CARDINAL) = 10957
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 37748754
WM_CLASS(STRING) = "netease-cloud-music", "netease-cloud-music"
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		user specified location: 1, 21
		user specified size: 1598 by 858
		program specified minimum size: 1022 by 670
		window gravity: Static