Version: (using KDE KDE 3.2.0) Installed from: Mandrake RPMs When a new Mozilla window is opened by clicking an icon on a toolbar or from K-menu, it always opens in background, if 'Focus stealing prevention' is set to anything other than 'None'. If it is started via ALT-F2 (Run Command) - it is started in foreground, as it should.
I'm not sure if it's related to kdeskrop, though, so please reassign it to wherever it belongs.
Are you sure this is related to how Mozilla is started and not e.g. to if it's already running? What exactly is the command used for starting it from KMenu (can be found out e.g. using kmenuedit)?
This only happens if 1) Mozilla is already running, and 2) Only if it is done using KDE menu or toolbar, or by any other mouse clicking procedure :) It doesn't happen if it is done by entering 'mozilla' in a konsole/xterm/whatever or in Run Command dialog. 'mozilla' is a script which starts a new Mozilla session if it's not started yet, or opens a new browser window if Mozilla is already running.
Are you sure it works fine when run from xterm (when mozilla is already running)? What is the (technical) difference when started from K-Menu and directly from xterm, I'd expect the K-Menu entry to use the same script like when run directly from xterm? Regardless of that, I see the problem too. I think I'll have to write a wrapper for such applications that don't have the necessary support for focus stealing prevention.
In case of XTerm and Konsole, a new Mozilla window will be opened under XTerm or Konsole window (strange - I thought it opened fine before, looks like I was wrong). However if ran from 'Run Command' dialog - works fine. Apparently, the new Mozilla window is opened under the current application, and in case of 'Run Command' it was that dialog, which disappears immediately, so the new Mozilla window becomes active.
The problem described in comment #11 of bug #48786 is the same like this. The problem is that the second instance of Acrobat/GIMP doesn't really launch, but instead tells the already running instance to open a new window. The problem is that they don't forward the user activity timestamp, so from KWin's point of view this is an inactive application (=first instance) suddenly opening a new window. The real solution is adding support to those applications, so far it's only possible to explicitly turn off focus stealing prevention for these window in window specific settings. Maybe it would be possible to write some hacking wrapper for these apps that would try to forward the timestamp somehow.
Please note in my comment #11 for bug #48786 that this still happens with: Focus stealing prevention level: None This is what makes it a serious bug -- you can't turn this new "feature" (?) off. From the description of comment #6, it appears that this feature can NOT be made to work correctly -- well at least it should be considered to be experimental -- and therefore even if this bug is fixed, the default should be: "None". -- JRT
Comment #11 from bug #48786 fixed.
Re my comment #7. I will confirm that it is now possible to turn it off in 3.3 BRANCH. I still wonder if this "feature" was a good idea. :-| The "Special Window Settings" works, but I think that there needs to be defaults for common applications that are known not to work. I also think that some additional general configure options might help (these are specific to my two test examples). Would it be possible to have a separate option (a check box): "Only KDE Applications"? I presume that all KDE applications would work even with: "High" or "Extreme". I also wondered if a different algorithm that permits all windows from applications running on the current virtual desktop to open and get focus might be a good option. Would that be lower than "Low" or might it replace "Low"? -- JRT
Ok, I'm afraid some wrapper scripts would be way too hacky. A workaround is creating a window-specific setting for the application and in the workaround tab force lower focus stealing prevention level. The real fix can be done only in the applications - since now GNOME will also support the feature, they'll have to fix it sooner or later anyway.