> Do you display icons too, or have them just in the icon manager?
> Maybe it waits for the icon window to appear?  Try to comment out
> all icon related styles in your configuration file and see if that
> helps (i.e. make fvwm use and display whatever icon pixmap or icon
> window the application provides).

 Unlike Tom Horsley, I display icons and I let Chrome use its default.
So between the two of us I think we cover all or very close to all of
the bases here. On the other hand the one thing neither of us does is
'iconify' Chrome to some sort of a menubar, which is what many common
desktop environments do.

(Tom hides Chrome entirely, I iconify it to a regular icon.)

 As Tom says, this is clearly a very recent Chrome behavior change.  On
the other hand it's at least a difference between what FVWM is doing and
what eg gnome-shell is doing (and I suspect KDE as well or there would
be many more bug reports to the Chrome people). I'm personally concerned
that the Chrome people will likely ignore bug reports about this unless
we can somehow identify what FVWM is doing differently.

Also, for anyone keeping track of this:
> Sounds pretty broken.  Other things to try are to resize the window
> or to restart fvwm or to use the "Recapture" or "RecaptureWindow"
> command.  Maybe clicking somewhere in the window where one of the
> controls should be helps?

 Sadly, recapturing doesn't help and clicking where controls are is
ignored just like keystrokes.

> Probably the window waits for some specific odd event that never
> comes.

 An odd event or maybe a sequence of events? Perhaps gnome-shell
deiconifies windows in a different sequence of X actions than FVWM
does?

(The other theory I can vaguely wave my hands about is that Chrome is
now waiting for some sort of OpenGL or compositor event in addition to
normal X events. Since FVWM doesn't do any of that stuff... but I
theorize extremely wildly and probably incorrectly.)

        - cks

Reply via email to