|Summary:||Some windows not coming to front as expected|
|Product:||[Fedora] Fedora||Reporter:||Aaron Gaudio <madcap>|
|Component:||metacity||Assignee:||Ray Strode [halfline] <rstrode>|
|Status:||CLOSED CANTFIX||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-08-14 15:45:58 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Aaron Gaudio 2005-06-21 19:15:53 UTC
Description of problem: Cetain apps which are supposed to be able to raise a window are failing under some cases. For example, I have gaim set to auto-raise when receiving messages. However, it only works sometimes, usually it will not raise the window. I can't find a sure way to reproduce it. Also, in NEdit, selecting another window from the Windows tab should raise that window, but it does not. Since this exists in two different apps using two different toolkits (gaim uses gtk and NEdit uses Motif), I suspect this may be a window manager issue. Version-Release number of selected component (if applicable): metacity-2.10.0-1 How reproducible: Almost always. Steps to Reproduce (in Gaim): 1. In Gaim, set the "Conversations->Raise IM window on events" option. 2. Start a chat with someone, and then obscure the window with another window (esp. one that is maximized). Have that person send you a message. Actual results: The Gaim chat window remains obscured. Expected results: The gaim chat window raises to front when the other person sends a message. Steps to Reproduce (in NEdit): 1. Open more than one NEdit window in a single session (using nc command line, or using File->Open/New from an existing NEdit window) 2. Obscure one of the windows. 3. From another NEdit window, select the obscured window from the Windows menu. Actual results: Nothing happens. Expected results: The selected window raises to front. Additional Info: Tested with gaim-1.3.1-0.fc4 and nedit-5.4-3
Comment 1 Aaron Gaudio 2005-09-01 14:11:24 UTC
I'd also like to note that when the window does not come to front as expected, it is instead made bold in the window list applet, as if it were newly opened. This operability is extremely frustrating, however, because it basically prevents auto-raising without having to select a window in the window list.
Comment 2 Ray Strode [halfline] 2005-09-01 14:18:18 UTC
Hi Aaron, This is a feature called "focus stealing prevention". There are various problems with allowing windows to pop up on their own any time they want. Let me give you an example. Say you are typing a document and a dialog pops up to inform you of something. If you are typing at a fast rate then you will be hitting space bar fairly frequently. If a dialog pops up quickly and you just typed space bar, then the space bar will activate the default button and close the dialog before you have a chance to read it. Focus stealing prevention detects if you are doing something. If you are then it prevents new windows from getting focused. Instead it makes the glow very noticeably in the task list of the task bar. You don't see any glow? What is the output of rpm -q metacity libwnck ?
Comment 3 Aaron Gaudio 2005-09-01 15:58:37 UTC
$ rpm -q metacity libwnck metacity-2.10.3-1 libwnck-2.10.0-4.fc4 Okay... I think I understand the idea behind focus stealing, but here are some issues I have with it: 1. With NEdit, I am manually selecting a window to bring to front from NEdit's menus. So, whether or not somebody thinks I'm "doing something" I definitely want the window to come up. However, I've noticed this seems to mainly happen with an older build of NEdit, not the latest build. I'm still investigating if there is any difference in the code controlling this. 2. With GAIM, I can choose the option of having it come to front or not on a new message. I choose the option to have it come to front precisely so it will interrupt me, and it is a major hassle to have to select the window in the window list to bring it to front. I can see many other circumstances where the logic between metacity/libwnck incorrectly decides not to raise a window. For instance in the case of gaim, it seems to not raise the window even when I'm not sitting at my desk, but occassionally (very occassionally) it will raise it when I am actually doing something. Philosophically, I differ with the approach metacity/libwnck seems to take, because I'd prefer applications themselves to decide how obnoxious they will be (and hopefully, to let me control it- per application). On the other hand, if the concern is focus stealing, then I see no reason that a window can't come to front without stealing keyboard focus, unless it completely obscures the current window (which is not the case with gaim); but again why not let the application developers control this? Regardless, I'd like a way to turn off this "feature". Is there any convenient way to do this (preferably without hacking code, but if I have to hack, I will)?
Comment 4 Ray Strode [halfline] 2005-09-01 16:50:42 UTC
Hi Aaron, I don't know of a convenient way to disable the feature other than downgrading metacity. Just out curiosity, do you have a window list (a series of buttons side by side on the panel) or a window selector menu (an icon in the corner of the panel that you click on to see a list of applications)?
Comment 5 Aaron Gaudio 2006-05-06 23:56:43 UTC
Ray, Wow, I never noticed this one as needing info (no email gets sent out when it changes to needinfo*). Yes, I do have a window list, and it does strobe the window buttons as designed. It's just inconvenient with apps like instant messenger apps in which you're holding a conversation while doing other things; especially when combined with metacity's obnoxious click-to-focus default (however I was just inspired to check gconf and see that they finally re-added that as a gconf setting... joy! so my concerns are less now because I can click back in my app without it always raising over my gaim window).
Comment 6 Christian Iseli 2007-01-22 10:09:57 UTC
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.
Comment 7 Aaron Gaudio 2007-01-22 14:45:56 UTC
The problem is actually kind of worse now. Gaim windows and the like still do not come to front, but they do strobe the task bar. However, NEdit windows do not even strobe the task bar when one attempts to raise an NEdit window from NEdit's Windows menu. This may be due to NEdit now being built with lesstif instead of openmotif. Whatever it is, it would be nice if it could at least strobe the task bar, and even better if the window would actually raise (since I'm in the same application that requested the window raise).
Comment 8 Ray Strode [halfline] 2007-08-14 15:45:58 UTC
The information we've requested above is required in order to review this problem report further and diagnose/fix the issue if it is still present. Since there haven't been any updates to the report in quite a long time now after we've requested additional information, we're assuming the problem is either no longer present in our current OS release, or that there is no longer any interest in tracking the problem. Setting status to CANTFIX, however if you still experience this problem after updating to our latest Fedora Core release and are still interested in Red Hat tracking the issue, and assisting in troubleshooting the problem, please feel free to provide the information requested above, and reopen the report. Thank you in advance. (this message is mass message)