[BUG] razor no longer floating window under i3wm

[alembiq]

I'm running ClassicUO 0.1.11.53 (UO Renaissance).

I'm using i3wm as tilling window manager under Manjaro Linux.

Up until recently, I was using razor 1.7.4.49, and everything was great :) Razor was a nice floating window.
Since I've updated to 1.8.61.0 razor is not willing to float, and it's behaving as a regular window, being stretched by the i3wm across the whole screen.

Older razors were floating without any configuration, but at this point I'm not able to make it floating again :(
Generally, when I want to make a window floating - I need to use xprop on the window and get its "WM_CLASS", and add it i3wm config. For some reason, WM_CLASS isn't part of the xprop output for any of the versions. But there are some differences that might have caused the change in window behaviour.

I can of course do a manual overload on any window, but I didn't needed to in the past :(

_NET_WM_ICON(CARDINAL) =        Icon (32 x 32):
_NET_WM_USER_TIME(CARDINAL) = 1674809855
_NET_WM_DESKTOP(CARDINAL) = 1
WM_STATE(WM_STATE):
                window state: Normal
                icon window: 0x0
I3_FLOATING_WINDOW(CARDINAL) = 1
WM_NAME(STRING) = "Razor v1.7.4.49"
_NET_WM_NAME(UTF8_STRING) = "Razor v1.7.4.49"
XdndAware(ATOM) = ATOM
WM_HINTS(WM_HINTS):
                Client accepts input or input focus: True
                Initial state is Normal State.
                window id # of group leader: 0x55e
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW
_NET_WM_STATE(ATOM) = 
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x2c, 0x3a, 0x0, 0x0
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
WM_ZOOM_HINTS(WM_SIZE_HINTS):
                program specified location: 1286, 60
WM_NORMAL_HINTS(WM_SIZE_HINTS):
                user specified location: 0, 0
                program specified location: 0, 0
                program specified minimum size: 104 by -3
                program specified maximum size: 530 by 379

_NET_WM_ICON(CARDINAL) =        Icon (32 x 32):
_NET_WM_USER_TIME(CARDINAL) = 1674809978
_NET_WM_DESKTOP(CARDINAL) = 1
WM_STATE(WM_STATE):
                window state: Normal
                icon window: 0x0
WM_NAME(STRING) = "Razor v1.8.61.0"
_NET_WM_NAME(UTF8_STRING) = "Razor v1.8.61.0"
XdndAware(ATOM) = ATOM
WM_HINTS(WM_HINTS):
                Client accepts input or input focus: True
                Initial state is Normal State.
                window id # of group leader: 0x55e
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW
_NET_WM_STATE(ATOM) = 
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x3e, 0x7e, 0x0, 0x0
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
WM_NORMAL_HINTS(WM_SIZE_HINTS):
                user specified location: 0, 0
                program specified location: 0, 0
                program specified minimum size: 538 by 384

[markdwags]

The change between those two versions was Razor window used to be locked to fixed since, in 1.8.61.0 I changed it to allow the user to resize it like most windows.

I'm not familiar with i3wm, but sounds like it takes windows that can be resized normally and stretches them instead of giving you the ability to control the size.

Does this issue occur on other apps that also are regular windows? I did confirm using mono, the window size works as expected, though not sure that helps you.

[alembiq]

i3wm as tilling manager generally stretches all the windows and tiles to the screen with the same size.
You can decide which of the windows goes bigger, and which is smaller, so you can resize it, and I can resize razor in this way.

Before the change happened, it was a floating window (as can could not change the size). Generally, I can make any window floating, but to do that, I need the app to have a property called WM_CLASS so I can specifically address it.
However, Razor doesn't have this property, so I cannot add a specific rule for it.
The tool I use to get WM_CLASS is xprop as showed above.