GNOME Bugzilla – Bug 268975
Window Manager Close Of Mail Compose Window Jumps In Stack
Last modified: 2005-10-11 21:22:28 UTC
This is really minor, but probably not something you can see on the console. It's more evident on remote displays. If you are in the Mail section and then start to composer a new message if you do a File-->Close after starting everything works correctly, it asks if you want to abort entry. If you use the window manager to do the same thing, the entire message flashes and goes behind the main Evolution window and then the dialog box comes up and then the message comes back over the top of the Evolution window. It's acting like the window manager is removing the window for a split second and then your code is bringing it right back again. If you can connect File-->Close to Window Manager "X" close, it should work OK.
i think this is a window manager issue, it works just fine here. we certainly do no window raising or anything ourselves.
I suspect it does do it on your PC, but being on the console it's so fast you don't see it. On our older thin clients, it's very evident. If you hit "New" and start composing an email message, move it on the screen so that it's over the top of the main Evolution window. Then type in a few names into the "To:" section. Then, hit the "X" of the window manager. The composer window jumps behind the main Evolution screen, then jumps back to the front and then presents you with the dialogs asking if you want to abort entry of the message. This takes about 2 seconds on our older thin clients.
I think what's happening is that the window manager is moving the composer window into the bg because it expects the window to be closed. however, since we pop up a dialog, the window manager immediately places the popup in front of all other windows and drags the composer to the front as well (behind the popup) because the popup is a child of the composer window. I don't think there's anything we can do in the evolution code to solve this.
I don't know the internals and trust that you all know best about this issue. I was hoping that WM_DESTROY could be connected to the same code as File-->Close from the pulldowns....which works as expected. Dialog appears over top of current window without the flashing issue.
i still think its a window manager issue - the wm i normally use simply NEVER does anything i didn't ask it to explicltly (i.e. it never re-orders depth). it seems to be something with metacity (i presume you're using that?). if they have a way we can hint (why should we have to?) that a close might not be a close, i guess they can let us know.
It's metacity. As I mentioned, it normally wouldn't be a big deal, except over Metaframe and low bandwidth (similar to VNC) you have a lot of bandwidth loss. It repaints the main Evolution window as the window goes to the back, and then repaints the child window again as it brings it to the front. One thing that I have not done is test with newer versions of Metacity. I'll add that to my list.
Not selecting "Reassign bug to owner of selected component" means that the maintainers of the module you reassign to will likely never see the bug... ;-) David: What version of Metacity? How are you "using the window manager to do the same thing"? Any chance you are accidentally hitting the middle mouse button (middle mouse button click anywhere on titlebar, even over the close button, means lower-window-to-bottom-of-stack)? I personally can't think of any other way that we lower an already showing window other than that, a special keybinding for lowering, or the application requesting it. Can you get a verbose debugging log? To get a verbose debugging log: - Reduce your desktop to as few windows as possible to reproduce the bug - Run METACITY_VERBOSE=1 METACITY_USE_LOGFILE=1 metacity --replace - On stdout metacity will print the name of the logfile - Reproduce the bug as quickly as possible - Kill the metacity you started above to stop the logfile from growing any longer - Compress the logfile and attach it to your bug report
Thanks for taking a peek at this one. I'll spend more time on it tomorrow. It's not a major issue, but has always bugged me over lower bandwidth lines. I'm testing a new HP thin client and because the chips is so fast you can barely see it happen. So I'm sure you never see it on a local video card. But on our older thin clients and over Citrix you can really see it. I'm attaching a shockwave movie that isn't perfect, but you can see it happen. The sample rate of vnc2swf isn't high enough to always pick up 1-2 second repaints on the screen. But basically in Evolution you do a File-->New and move the composer window so it obscures part of Evolution and then type some text into the lower pane. Then click on the "X" Exit button. What happens is the composer window flashes behind Evolution for a second (more over low bandwidth), Evolution repaints, then the composer window comes back to the front and has to repaint and then the dialog opens over the top asking if you want to quit out of the message. metacity is metacity-2.4.55-7.1 on RH Ent 3.
Created attachment 53343 [details] Shockwave movie of Evo composer flipping to the back and then forward again. Not perfect, sample rate is not high enough always to see 1-2 second screen changes.
Okay, so by "using window manager to do the same thing" you mean using the mouse to click the close button (as opposed to using the alt+F4 global keybinding or something else). That's what I suspected. Anyway, now that I know which version you are using (didn't that version have a code name of "prehistoric" or "older-than-dirt"?), I tried it out myself and also went digging in the code for clues and found a link to a certain bugzilla bug pointing out something useful--this bug was fixed before I started helping with development on Metacity. :-) fejj nailed the problem on the head too. He was quicker than I was when I read over the bug report. Anyway, I'll cc the evo maintainers just in case they know of any other reports like this so that they know they can close them. *** This bug has been marked as a duplicate of 108706 ***