Created attachment 34409 [details]
No window title

Btw: It appears that it does work on KDE (atleast that's what I'm told, I'm not
coming anywhere near a KDE desktop)

In a terminal, please type
   xprop | grep "^WM.*NAME"
then click on the title-less Java window, then copy-and-paste the terminal
output into this bug report.

Outputs absolutely nothing.

The full output is this:

_NET_WM_ICON_GEOMETRY(CARDINAL) = 777, 1026, 245, 24
_NET_FRAME_EXTENTS(CARDINAL) = 4, 4, 21, 4
_NET_WM_DESKTOP(CARDINAL) = 2
WM_STATE(WM_STATE):
                window state: Normal
                icon window: 0x0
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x1, 0x1, 0x4e0050, 0x18
_NET_WM_STATE(ATOM) = 
WM_HINTS(WM_HINTS):
                Client accepts input or input focus: False
                Initial state is Normal State.
WM_NORMAL_HINTS(WM_SIZE_HINTS):
                user specified location: 0, 0
                program specified location: 0, 0
                program specified size: 435 by 183
                window gravity: NorthWest
WM_PROTOCOLS(ATOM): protocols  WM_TAKE_FOCUS, WM_DELETE_WINDOW
WM_CLASS(STRING) = "sun-awt-X11-XFramePeer", "DozoWereld"
WM_CLIENT_LEADER(WINDOW): window id # 0x3200007

There's no title set on that window... what title shows up in KDE?
Maybe it displays the WM_CLASS or something?

I guess it does, all I know is that the title is displayed correctly on KDE
(although I can't confirm that, haven't seen/touched KDE).

The title that should be shown is "DozoWereld", so if it would display the
WM_CLASS, it only displays the second part.

Created attachment 35072 [details] [review]
Deal with apps that don't set any *_NAME properties

This patch:
  1) Moves set_window_title and set_icon_title from window-props.c to window.c
     and exports them (which includes a slight rename).
  2) Adds a title_set flag
  3) In the update_wm_class, if the title has not yet been set, then set it to
     the WM_CLASS.

Comment on attachment 35072 [details] [review]
Deal with apps that don't set any *_NAME properties

I'm a little skeptical this is a good idea unless the specs say we should do
this; maybe if twm and mwm did it at least I'd feel better. If this is a
kwin-only behavior I'd say we should back it out of kwin and get the apps
fixed.

I think I'd skip window->title_set, instead have 
window->using_wm_name
and window->using_wm_icon_name then use the class if neither other property is
in use.

Note that the whole thing is dependent on the order of loading the properties;
so we should probably check that the order is right and add a comment not to
reorder them.

To avoid the order dep we'd have to keep around the value of all three
properties and I don't want to use that memory.

if we kept title_set I think it has to be a different flag for title and icon
title.

Slightly nicer than moving set_title() into window.c might be to port
update_wm_class() into window-props.c framework (write a reload_wm_class
basically)

It'd be a nice general cleanup btw to get all the window properties into that 
initial_props array rather than having all the update_* functions.
Then you get to nuke most of the property_notify() function too.

> I'm a little skeptical this is a good idea unless the specs say we should do
> this; maybe if twm and mwm did it at least I'd feel better. 

I went looking, but was unable to find anything that said we should do this. 
However, apps are not required to set any of WM_NAME, WM_ICON_NAME,
_NET_WM_NAME, or _NET_WM_ICON_NAME by either the ICCCM or EWMH.  (The EWMH does
state that apps SHOULD set it, but not MUST.  I couldn't find anything as far as
requirements for apps in the ICCCM--it seemed to focus only on WM requirements).
 So, it appears to be perfectly valid for apps to be stupid, like this Java
example.  WM behavior appears to be undefined in this case.  Maybe we should
request that the EWMH define it?

> If...I'd say we should...get the apps fixed.

Actually, I'd prefer that over this patch.  Using WM_CLASS seems like a lame
punt/hack to me.

> Note that the whole thing is dependent on the order of loading the properties

Right, and this is perhaps slightly complicated by the fact that the ICCCM
explicitly forbids WM_CLASS changes unless the window is withdrawn, whereas
there is no such requirement on any of the *_NAME properties.
 
> port update_wm_class() into window-props.c framework

Does that make sense given that the ICCCM explicitly forbids change WM_CLASS
unless the window is withdrawn?  I thought (but didn't check) that the reload_*
functions where for things that could change more dynamically...

The main point of window-props.c isn't for dynamic changes (though it simplifies
that), the main point is to load all props for a new window in a single round trip.

I'd hazard a guess that this is not a common case (since it has not been
reported previously) so marking minor and confirming (based on the conversation :)

Fixing the title...

bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years.

If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/

Thank you for reporting this issue and we are sorry it could not be fixed.