At Fri, 23 Jan 2009 11:51:03 +0100 Julien Danjou wrote: > Hi, > > Maarten, I allow myself to ping you about a problem I discovered. > This is somehow a race condition that I first realized with the > "Opening" dialog box from Firefox when clicking on a link to a > downloadable file. > > If you click on the link, and immediately switch to another tag, this > happens: > The window is tagged along with firefox tags since they are in the same > group. Since you are not on Firefox tag, the client is banned right > away. > When you come back the "Opening" dialog is not visible, it is out of the > screen. (xwininfo show that it is placed where it has been moved for > banning) > > In fact, the following happens: > - window is managed. > + it request position 0,0. > + window is banned immediately to negative coords. > - Since windows is banned (but mapped), Firefox send just after > a (useless) ConfigureRequest with coords set to the _negative_ > coords (the one used to ban the window). > awesome honors that and register the new coords instead > so 0,0 is replaced with the negative coords. > - You switch back the tag where Firefox is: the window is hide > in negative coords, since it's unbanned with c->geometry > which are negative due to the ConfigureRequest. > > The thing is that since the window is not unmapped anymore when banned, > clients thinks they are visible and that the coords they were moved to > are the correct ones. > > I'm not sure how to fix that actually, so in case you have an idea. > > Cheers
What about either ignoring configure requests on banned windows or postponing
the application of the configure requests until the windows are unbanned?
The latter one imho looks better, but the former might be way easier to
implement.
--
Gregor Best
signature.asc
Description: PGP signature
