Stefan Blachmann <sblachm...@gmail.com> writes: > On 8/24/18, hw <h...@adminart.net> wrote: > >> But that doesn´t work either, the windows are placed on top of each >> other again. With !UsePPosition alone, I get the windows placed as I >> want it, but it means Firefox is moving them rather than that fvwm >> places them. > > Yes, FF creates its windows with the size given in sessionrestore.js, > *then* moves, retitles and paints them. You can see the detailed > sequence this is done in the sessionrestore code. > You might notice some of these freshly-created windows flashing up for > a *very* brief moment before "disappearing" again. > If you configure FvwmWindowList to show the window coordinates, then > you can easily see "where" the windows are.
I can see that they are being placed on top of each other rather than side by side. Fvwm does prevent the windows from being moved. Only it doesn't place them according to the placement policy. It looks as if fvwm doesn't know that there are already windows from Firestorm on the screen when deciding about where to place them. > On 8/25/18, Dominik Vogt <dominik.v...@gmx.de> wrote: >> It actually is possible. Sort of. If the application claims that >> a requested position is "user specified" instead of "program >> specified", the window manager has no way of knowing that the user >> did not ask for it. Nowadays many programs abuse this hint to >> override the window manager - in clear violation of the >> communication rules set in the ICCCM2 standard. > > Well, Firefox is correct if it says "user specified" position, as > *you* probably were the one who originally specified it by moving the > window. > > Firefox moves windows off-screen when playing something fullscreen by > Flash, and maybe even HLS.js too, so I guess the underlying cause of > our problem is that Firefox stores these temporary positions *instead* > of the original ones (i.e. those before switching to fullscreen > playback) when it does its regular sessionrestore.js file updates. > > So, may I ask, did Firefox crash in full screen video playback mode? > Or what did happen before the problem of incorrect session restore arised? In my case, the problem was with Seamonkey. I'm using a desk with 4 by 4 pages. That makes it possible to place windows like this, the dots being the windows: 1 2 3 4 |---|---|---|---| | | . | | | 1 |---|---|---|---| | . | . | . | | 2 |---|---|---|---| | | . | | | 3 |---|---|---|---| | | | | | 4 |---|---|---|---| On the next start, Seamonkey would restore the session, including this window layout. You can imagine what happens when it does so relative to the window in the middle (the one at (2, 2)) when you start Seamonky on page (1, 1) instead: You can get two unreachable windows. Setting FixedPPosition fixed that for Seamonkey. With Firefox, I think using FixedPPosition, !UsePPosition fix it as well, but the problem is that for some reason, fvwm does not place the windows according to the placement policy. If you want to try: Style * MinOverlapPercentPlacement Style * FixedPPosition Style * !UsePPosition Style * !UseTransientPPosition Style * DecorateTransient Start Firefox and make it so that it has three windows. Now place these windows all side by side on the same desktop page so that they do not overlap any other windows or each other. Close Firefox and see what happens when you restart it: The three windows are being placed on top of each other at the top left corner of the page. Why is that? This is just wrong, isn't it? > Because, maybe the best thing we can do is to collect as much > information about the problem as we can, so we can file a helpful > Firefox bug report that actually enables Mozilla to get that fixed? I'm not sure that fvwm is entirely innocent in this case. I'm not entirely sure that there is something that Mozilla needs to fix because when I let Firefox do its thing, it restores its windows as they were. If they already fixed creating windows at unreachable places, what is left for them to fix? > P.S.: I also had instances of LibreOffice hanging offscreen, in every > case following some (major?) update. Seems it does no version-check > its preferences+session files, as deleting these always fixed the > problem for me. Hm, we use that quite a bit at work, and I actually kinda like how it remembers the position and the size of the window. I´ve never had problems with LO creating windows at unreachable places. Do you still have this problem with the Styles above?
