On Fri, Sep 05, 2014 at 04:46:50PM -0400, Chris Siebenmann wrote: > > Also, please try to grab the bottom border of the bad window, and > > drag it all the way up to the title bar (in opaque resize mode, > > not in wire frame mode). Stop resizing, then resize the window > > again to its original size. > > This has no effect, but during the opaque resize things flicker > and I can occasionally see flashes of bits of window content.
Sounds really broken. > > One more thing to try: Does maximizing and unmaximizing the window > > help? Or making it sticky and unsticky? > > Maximizing and unmaximizing the window has no effect. > > However, making it sticky and then unsticky is a winner; the moment > I make it sticky the window contents pop back (and they stay when I > unsticky it again, until I iconify it again). In addition while the > window is set sticky I can iconify it and then deiconify it and the > contents stay visible. Actually, stickyness and maximization are Ewmh window states - just like shading. That's why I suggested trying them. So, if you replace deiconify with AddToFunc Deiconify + I iconify off + I stick toggle + I stick toggle That should hide the problem without a lot of resizing and moving the window around. On Fri, Sep 05, 2014 at 04:57:29PM -0400, Tom Horsley wrote: > I'm not really sure it is worth trying to fix from the fvwm side > now that we have a work around. No, of course not; I won't add crazy stuff to window handling jsut because of one broken application. It might be worthwhile to add another BugOpts option (or a style) that makes fvwm tell windows that they are shaded when they are actually iconified. > This has got to be a chrome bug > google ought to fix (doesn't it?, he queried hopefully :-). I hope so, but things can take a long time until they're fixed. (Please don't send replies to me directly but only to the list.) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
