From: ebik <eb...@uc...> - 2012-01-18 10:03:00
|
Hi, Maybe the most 'correct' behavior is unmap, set/reset _NET_WM_* property, and then map. So any mapped window will have proper value of the property. There may be always some application, that takes action on change of the property and assumes that it is mapped, but that is a bug without any doubts. Is it possible to call XUnMapWindow first, then change the property and then call XReparentWindow ? Will it help? On Wed, 18 Jan 2012 00:40:17 +0100 Philipp Hartwig <ph...@ph...> wrote: > I'm not comfortable with the sf.net tracker so please allow me to > make this rather long comment on bug 3429909 [1] via mail. After > spending many hours with Notion and Firefox in gdb I now understand > what is going on. It all comes down to the following behavior of > Firefox: > > Assume that > a) Firefox is in its internal normal mode and > b) _NET_WM_STATE_FULLSCREEN is set for the Firefox window. > Now call first XUnmapWindow and then XMapWindow on the Firefox window. > > Result: Firefox switches to its internal fullscreen mode and requests > to be put into fullscreen mode via a _NET_WM_STATE client message. > Let me call this behavior (B) for reference below. I don't understand > how it is a reasonable behavior. > > You can easily reproduce (B) via the following function in > ioncore/netwm.c which can be bound to a key and then applied to > Firefox: > > --- SNIP --- > EXTL_EXPORT_AS(WClientWin, ffdbg) > void firefox_debug(WClientWin *cwin) > { > CARD32 data[1]; > int n=0; > > data[n++]=atom_net_wm_state_fullscreen; > XChangeProperty(ioncore_g.dpy, cwin->win, atom_net_wm_state, > XA_ATOM, 32, PropModeReplace, (uchar*)data, n); > XSelectInput(ioncore_g.dpy, cwin->win, > cwin->event_mask&~(StructureNotifyMask|EnterWindowMask)); > XUnmapWindow(ioncore_g.dpy, cwin->win); > XMapWindow(ioncore_g.dpy, cwin->win); > XSelectInput(ioncore_g.dpy, cwin->win, cwin->event_mask); > } > --- SNAP --- > > How does this explain the behavior of Firefox that we are seeing with > Notion's and Firefox's fullscreen mode? First let me note that > according to its man page, XReparentWindow involves an XUnmapWindow > followed by a XMapWindow so it will trigger (B) if conditions a) and > b) are satisfied. > > Let cwin be a Firefox window. I write cwin_n and cwin_f to denote > wheter cwin is in its internal normal or fullscreen mode, > respectively. > > 1a) > Start with an ordinary cwin_n and call Notion's fullscreen toggle > function region_set_fullscreen. > We soon land in > clientwin.c:clientwin_fitrep > Here we have > do_reparent_clientwin => XReparentWindow(.., cwin) > But note that do_reparent_clientwin is called before > netwm_update_state(cwin) so that condition b) is not satisfied and > (B) is not triggered. No other XUnmapWindow(..., cwin) is called in > the course of region_set_fullscreen. > > Conclusion (and observation): We end up with cwin_n in Notion's > fullscreen mode (and with _NET_WM_STATE_FULLSCREEN set!). > > 1b) Again call Notion's fullscreen toggle function. As above we get to > XReparentWindow(.., cwin) > and as netwm_update_state(cwin) was not yet called, condition b) is > satisfied. So by (B) cwin_n becomes cwin_f and requests to be > fullscreened, which we do. > > Conclusion (and observation): We end up with cwin_f in Notion's > fullscreen mode. > > 1c) Again call region_set_fullscreen. This time (B) is not triggered > because condition a) is not satisfied. > > Conclusion (and observation): We end up with cwin_f in Notion's > normal mode. > > [Side note: Another instance of (B) can be observed if, at the end of > 1a), you switch away from and then back to the fullscreened cwin_n. > Switching away calls an XUnmapWindow, switching back to it calls a > XMapWindow and consequently cwin_n will become cwin_f.] > > 2a) > Start with an ordinary cwin_n and press F11. cwin_n changes itself to > cwin_f and requests to be fullscreened which we do. Here no surprises > happen. We end up with cwin_f in Notion's fullscreen mode with > _NET_WM_STATE_FULLSCREEN set. > > 2b) Press F11. cwin_f changes itself to cwin_n and requests to be put > into normal mode which we do. But as in 1b) above we call > XReparentWindow before we remove _NET_WM_STATE_FULLSCREEN. So (B) is > triggered and cwin requests to be fullscreened again. We end up with > the situation we started with. > > This concludes my analysis. If we believe that all our problems come > from (B) it is not surprising anymore that for example dwm[2] does > not suffer from them as it never calls XUnmapWindow. And most other > window managers seem to use XCB instead of Xlib which also doesn't > seem to suffer from (B). > > Isn't (B) a clear bug in Firefox? If so I think that the winprop > kludge is the way go to. Also the analysis doesn't seem to indicate > any other obvious solution, does it? My main goal was to understand > what is going on and why other wm's don't have the same problem. > > Any comments are very welcome. Have I overlooked something? > > Regards, > Philipp > > [1] > http://sourceforge.net/tracker/?func=detail&aid=3429909&group_id=314802&atid=1324528 > [2] http://dwm.suckless.org/ > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft > developers is just $99.99! Visual Studio, SharePoint, SQL - plus > HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when > you subscribe now! http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > Notion-devel mailing list > Not...@li... > https://lists.sourceforge.net/lists/listinfo/notion-devel > -- Tomáš 'ebík' Ebenlendr Centrum Holdings s.r.o. PF 2012.04761630996 |