bug#31650: 26.1; Desktop mode adds wm stickiness to emacs windows.

[Rolf Ade]

>> I start emacs -Q. The frame comes up and isn't sticky.
>>
>> Now I evaluate your code from above in the scratch buffer. It returns
>> nil. _But_: It also puts the frame into sticky mode!
>
> Does it also make the frame sticky when with emacs -Q you simply
> evaluate
>
>       (set-frame-parameter frame 'sticky nil)))

It's not exactly clear to me what code you ask me to evaluate (the code
above isn't syntactically correct or only a part of the code you want me
to evalute.

If I start emacs -Q and evalute just

(dolist (frame (frame-list))
  (set-frame-parameter frame 'sticky nil))

in the scratch buffer then, yes, this also puts the frame into sticky
mode.

> If so, then it would be helpful to debug x_set_sticky, set_wm_state,
> x_send_client_event and x_fill_property_data to know which value gets
> propagated there.  As it stands, it seems that we always turn on
> stickyness when setting this frame parameter to nil, so somehow the
> chain above seems to corrupt it.

Hm. From looking around I see that x_set_sticky and set_wm_state are C
functions in xterm.c and x_send_client_event and x_fill_property_data
are C functions in xselect.c.

I guess you mean I should run emacs under gdb, set breakpoints to that
functions and inspect the arguments given to the calls. Unfortunately
I'm not used to gdb.

With the help of etc/DEBUG (part of the emacs source distribution) I was
able to start emacs from within emacs with the help of M-x gdb, to set
break points to this four functions and run the new instance, with
execution stoping at my breakpoints.

But I'm unsure what information could help to understand the problem (I
guess, the values of the function parameters?) and how to gather them in
a way that provide insight.

I'd appreciate more detailed hints what (and how) I should look for.

Thanks,
rolf