1790290 - Window class is not immediately fully set when application window is initially mapped

Status: RESOLVED WORKSFORME

(Thunderbird :: Installer, defect)

Description

[Phil Stracchino]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:104.0) Gecko/20100101 Firefox/104.0

Steps to reproduce:

Behavioral change:
With prior versions of Thunderbird I could use the window class string "Mail" to identify Thunderbird's main window, and place it at a specific position on screen (-0 +0) using an FVWM InitialMapCommand. xprop used to report the two window class strings "Mail" and "Thunderbird" for the main window.
This no longer works in version 102, because at the time that the main window is initially mapped, it appears the window class "Mail" has not yet been set, and is still only "thunderbird" (vs. previous versions' "Thunderbird"; I assume this is a typo). I can only auto-place the main window by using the window class string "thunderbird", and that of course causes ALL Thunderbird windows to be placed at (-0 +0), which is not the desired placement behavior.

Comment 1

[Phil Stracchino]

Additional information -- class/resource upon creation:

[fvwm][AddWindow]: new window:
name: Mozilla Thunderbird
icon name: (unknown)
resource: Mail
class: thunderbird

Comment 2

[Thomas D. (:thomas8)]

Rob, is this installer territory?
Have we deliberately changed the window class?

Phil, would your tool be able to read out resource: in addition to class? Because "Mail" is still present, but now under resource:...
Do you know more about best practices/standards for these window markers?

Comment 3

[Phil Stracchino]

(In reply to Thomas D. (:thomas8) from comment #2)

Rob, is this installer territory?
Have we deliberately changed the window class?

Phil, would your tool be able to read out resource: in addition to class? Because "Mail" is still present, but now under resource:...
Do you know more about best practices/standards for these window markers?

Thomas, the tool is plain bog-standard xprop. Yes, it reads out resource as well as class, and something that was pointed out to me by the fvwm dev team is that it LOOKS as though what happened is the class and resource were inadvertently swapped somehow.

Comment 4

[Rob Lemley [:rjl]]

Hmm.. it's not the installer, that's a Windows-only thing.

I'm not sure where/how WM_CLASS gets set, but what Thunderbird is setting appears to be consistent with what Firefox does, at least on my machine:

Thunderbird xprop snippet

WM_WINDOW_ROLE(STRING) = "3pane"
WM_CLASS(STRING) = "Mail", "thunderbird"

Firefox xprop snippet

WM_WINDOW_ROLE(STRING) = "browser"
WM_CLASS(STRING) = "Navigator", "firefox"

I threw the WM_WINDOW_ROLE in there... if you can use that it may be available when you need it? I have never used FVWM, so I'm a bit lost here.

Comment 5

[Phil Stracchino]

(In reply to Rob Lemley [:rjl] from comment #4)

Thunderbird xprop snippet

WM_WINDOW_ROLE(STRING) = "3pane"
WM_CLASS(STRING) = "Mail", "thunderbird"

Firefox xprop snippet

WM_WINDOW_ROLE(STRING) = "browser"
WM_CLASS(STRING) = "Navigator", "firefox"

Yes, the data is good once a window is completely initialized. The problem is that WM_CLASS does not contain "Mail" at the time the window is initially mapped. When a Thunderbird window is created, WM_CLASS contains only "thunderbird", and "Mail" or "Msgcompose" does not appear until as much as several seconds later — by which time FVWM has long since finished with it and gone off to do something else. I was able to find a workaround to place Thunderbird's main window, but the workaround I eventually found was to code a 3-second delay into the InitialMapCommand function for Thunderbird so that FVWM waits until three seconds after the window has been created before it tries to place it.

That's the real heart of the problem here, which I see I may have failed to fully and clearly explain. The WM_CLASS data is EVENTUALLY correct (like MongoDB is EVENTUALLY consistent), but at the time the window is created and presented for mapping/placement, WM_CLASS does not yet contain the "Mail" string. It USED to be the case that the main window was created with its WM_CLASS fully populated. Now "Mail" is not there until more than two seconds after the window appears. THAT is the fundamental behavioral change that is breaking smart window placement-by-name.

Comment 6

[Rob Lemley [:rjl]]

Two questions:

• Do you do something similar for Firefox 102esr? I'd like to know if "WM_CLASS" has "Navigator" right away or if there is a similar delay. This can help with narrowing down where the bug may be in the code.
• How flexible is the mapping tool in FVWM? Can it use "WM_WINDOW_ROLE" matching "3pane" instead assuming it's available early enough?

Comment 7

[Phil Stracchino]

(In reply to Rob Lemley [:rjl] from comment #6)

Two questions:

• Do you do something similar for Firefox 102esr? I'd like to know if "WM_CLASS" has "Navigator" right away or if there is a similar delay. This can help with narrowing down where the bug may be in the code.
• How flexible is the mapping tool in FVWM? Can it use "WM_WINDOW_ROLE" matching "3pane" instead assuming it's available early enough?

Rob,
The problem does not occur with Firefox, only with Thunderbird. I've tried without success to determine exactly how large the delay in populating WM_CLASS with "Mail" is. I've been experimenting a bit more with the mapping function today trying to troubleshoot the problem, and refresh my memory of the exact behavior. In so doing, I HAVE found a workaround.

I USED to use:
Style "Mail" StartsOnPage 3 0, InitialMapCommand Move -0 +0

This no longer works because when the window is first mapped, WM_CLASS does not yet contain the string "Mail", so that Style rule does not trigger and the Move is not executed.

I tried changing that to:
Style "thunderbird" StartsOnPage 3 0, InitialMapCommand Move -0 +0

This works, but moves ALL Thunderbird windows to (-0, +0), not just the main window.

Currently what I am using is,
Style "thunderbird" StartsOnPage 3 0, InitialMapCommand ForceMailPlacement Mail -0 +0
where ForceMailPlacement() is:
AddToFunc ForceMailPlacement I ThisWindow ($0) Move $1 $2

This works because "thunderbird" is present in the WM_CLASS when the Style is matched, even though "Mail" is not, so the Style rule match is triggered as intended; but by the time InitialMapCommand() is executed, calls ForceMailPlacement(), and ForceMailPlacement() has resolved $0 to "Mail", NOW "Mail" IS present in WM_CLASS, and so the Move command works, but only on the main window, which is what I want. It APPEARS that WM_CLASS is now being populated soon enough that I no longer need a delay in ForceMailPlacement(), but not soon enough for the direct Style "Mail" ... Move ... form to work.

FVWM's window styles (which are how mapping placement is assigned) are assigned by matching against either WM_NAME or WM_CLASS, but not any other property.

Comment 8

[Rob Lemley [:rjl]]

I finally tracked down where some of these values are coming from: https://searchfox.org/mozilla-central/rev/670e2e0999f04dc7734c8c12b2c3d420a1e31f12/widget/gtk/nsWindow.cpp#6344-6404

When a window is created, the "windowtype" attribute is read. For the main Thunderbird window, that is "mail:3pane", for a composer window, it's "msgcompose". SetWindowClass() is called with that value as its argument.

SetWindowClass splits windowtype on ":" into res_name and role, and capitalizes the first letter of res_name. Resulting in "Mail" and "3Pane". If the ':' split fails, res_name and role are both set to the entire windowtype string, again capitalizing the first character. "MsgCompose".

Those two values are saved to a couple of globalish variables and RefreshWindowClass() is called. It calls gdk_window_set_role and then does some magic to call XSetClassHint using gdk_get_program_class() and res_name. gdk_get_program_class() by default returns the executable name if gdk_set_program_class() isn't called previously (and it looks like it is not.)

I still don't know why there's a delay when a 3Pane window is opened, but at least we know how the values are determined.

Comment 9

[Thomas D. (:thomas8)]

Rob, Phil, is there anything which you still want to do here? (Otherwise we should close this bug...)

Comment 10

[Rob Lemley [:rjl]]

There is the matter of the delay setting WM_CLASS. That sounds like a bug, though I've not confirmed it.

Comment 11

[Phil Stracchino]

(In reply to Thomas D. (:thomas8) from comment #9)

Rob, Phil, is there anything which you still want to do here? (Otherwise we should close this bug...)

I've got a workaround for my specific use case, but something went wrong to cause the problem in the first place.

Comment 12

[Wayne Mery (:wsmwk)]

Reporter, do you still see this issue when using the latest version?
What information can you add to clarify the steps to reproduce this issue?

Comment 13

[Phil Stracchino]

I have just retested with 102.9.1, and the problem APPEARS to be fixed. I can now force initial placement of the main window in fvwm2 using window class "Mail" again.

Comment 14

[Phoenix]

Resolved per whiteboard and Comment 13