'Downloading package information' and 'building dependency tree' progress dialogs request focus too often

Thanks for the bug report. Yes, this is annoying...

This is fixed in my local repository and will be part of the next version. There was an option in the glade that I missed.

Sebastian

Thanks for your bugreport and thanks to Sebastian for the patch.

I uploaded a package that contains the changes from Sebastian and mark the bug closed now.

Thanks,
 Michael

This bug is still open... Should it be closed?

Depends if you want to veer off on a tangent, or open a new bug. It still does it when actually installing the updates.

It's rather annoying, because it does it twice (download, then apply), and also raises. I'm using XFWM as my window manager, and it set to neither raise nor give focus to new windows, and to try to prevent windows from stealing focus. This works on other GTK+ apps, so I'm guessing that u-m does something odd.

It's getting fixed? Yay! I have a long terminal window which is blocked by the "bubble" that shows there's new updates available, so to make it go away, I tend to click it - and that's a bad reflex: my routine login sequences on said terminal get all messed up when the focus suddenly hops over to the update window while it works...

By the way, I appreciate the fix to said update-manager that made it ask for my password only after I remember to tell it to start updating instead of immediately! That was also a major process-disturber that's now gone. :)

--Sini likes to keep her Ubuntu updated

This is actually a bug in the metacity window manager. Perhaps it is good to have this bug open to avoid duplicates in the future. Compiz handles child dialogs better.

is this metacity window manager bug reported upstream?

http://bugzilla.gnome.org/show_bug.cgi?id=357702

I've reassigned this to metacity in Ubuntu, since that's getting the blame for this bug.

I can't reproduce this in Ubuntu 7.04 updated to 23rd March with 'Update Manager' - no version information, no 'About' button.

I still see this problem in Feisty..

Please do not push bugs.

"Please do not push bugs."

This behavior is still present (and very annoying) in Gutsy.

-H-

(and also present in Xfce - even with 'focus stealing prevention' on)

I've always liked linux mechanisms for dealing with multiple windows. This is not the case anymore since apps are constantly stealing focus. For example, I'm running update manager in the background while composing email in thunderbird. I start typing address, puff, update manager stole focus. Click back to address field and again, update manager is in the front. This is just one of many examples on Gutsy.

Contrary to Sebastian's comment in February, Compiz also exhibits this behaviour, so I don't think the entire blame can be placed on metacity.

Nothing else on my Gutsy system behaves like this, so it has to be something update manager is doing differently - although I can't figure out what that is. It's incredibly irritating though (and makes me wonder - why pop up a window at all? Why not swap out the existing contents for a progress display? That's another bug of course).

This still exists, and is very annoying. IMO, it's unacceptable to be typing something and have the focus stolen so that you have to refocus the window you were working on.

I would like it if you could minimize the update window to the notification area, and it would just go away once the updating was completed.

I confirm the bug exists on gutsy and is realy annoying since we need to run that application almost every day and each time it steals the focus.
update manager is key application in ubuntu so I would expect it to behave cleanly. Currently it looks like a program from 1980 with subwindows/ dialogs poping up everywhere and terminal output that does not event tell us when the process is finished.

Still exists on Hardy (alpha 5, updated as of 2008-03-01) with or without Compiz.

Extremely annoying. It's only semi-possible to work on anything else while updates are installed, because every so often Update Manager steals focus right in the middle of whatever.

I have also noticed this.

The "Update Manager" steals focus quite a lot. Its a bit annoying.

on hardy, it still does this.

Bug #35876, first reported on 2006-03-21...

Its been 2 years, and it still isn't fixed.
Does it really take that long to fix something simple as an application stealing focus?

Have you tested with trunk and confirmed it still does this?

It seems this is fixed with latest hardy updates. Only those windows get on the top of others that needs users input.

That isn't optimal either, actually it's the worst part:

I might be typing something in another application (an update takes a long time, which is why I minimized it in the first place). If a window needing input pops up unexpectedly and steals the focus, it's extremely likely that my last few key-strokes will get sent to the wrong window (i.e., the stealer). In cases where those key-strokes happen to mean something they can cause unwanted effects.

For instance, if I copy something and Nautilus asks me if I want to overwrite a directory (generally some destructive operation, it wouldn't ask otherwise), it would potentially cause a disaster if I was just happening to type a word that contains "y" (or any of the active shortcuts). If the update manager asks for input I can similarly cancel and loose an error log, or (un)install something I didn't want to. If I left something working for an hour to do something and then it asks me what to do with it and I accidentally tell it to just exit, I'd be very annoyed.

On several occasions I've had text windows and even terminals coming up while I was typing a password in another window. The effect of that is that (at least part of) my password is visibly typed on the screen, and someone can see it. If I also press enter before I notice the intruding window, the password can even be interpreted and get written in some log, etc.

Although rarer than typing, I've also seen (surprisingly often) cases where I typed a close command (alt+w or alt+f4) intending to close the window I'm working in and closed some window that happened to steal the focus. This can also cause lost data.

========

In general, focus should not pass to another window unless as a direct _and_ immediate effect of some explicit user action. In particular, the window manager is responsible to do that between applications. (It can't really do anything if a program incorrectly moves its focus.)

So, except for explicit alt+tab (and similar commands, for instance for switching workspaces), there should be _very_ few exceptions to the rule.

The only case I can think of is when the user does something like "run terminal" (which is a WM short-cut command) _and_ the terminal shows up very quickly (ie, under a second).

========

Note that putting the window on top without giving it focus is much less destructive, but it can be annoying. Also, if the new window is full-screen (or just large), it can be very annoying to the user (who suddenly can't see what he was doing).

Of course, if you just leave the window in the background, that's also annoying because the user won't notice it.

The best solution I've yet to see is how OS X makes icons "jump" on the task-bar when they need attention. That's very visible, but doesn't prevent the user from doing whatever he was doing, and it's also easy to ignore on purpose.

(Windows does this by blinking the application in the task-bar, but that's more annoying with auto-hide because it's harder to ignore.)

I should note that, although I don't know the specifics of the problem and so I can't say whether it's been fixed, Robert's answer is certainly not the whole truth. Metacity has no way of knowing whether a window needs input.

Metacity policy (and also the policy of any other sane WM, as Bogdan mentions) is that applications should never be able to steal focus. When a window attempts to steal focus, we intercept it and blink the icon on the taskbar, much as Windows does. Application authors often think this is a bad idea, and try to figure out ways of stealing focus, so we're always having to find new ways to stop them. (Of course, there are also bugs in our prevention mechanisms to fix.) It is possible that you have found a case where an application can steal focus; if so it is important it's fixed. Focus stealing is an important matter to us, almost as important as crashes, and I will make it a priority to fix things if you can give me a reproducible case we agree is a problem.

Thomas, the issue there is easy, just write "sleep 8; gtk-demo", switch to your webbrowser to type something and notice the gtk-demo stealing the keyboard

write "sleep 8; gtk-demo" on a command line rather

So it's not just existing windows raising themselves, or newly-created transients of existing windows: even newly-launched applications shouldn't appear over the top of the current one? What about if, say, I choose them from the "Applications" menu; should they steal focus then?

This should be split into two separate bug reports:

1. Synaptic and update-manager trying to steal focus (they shouldn't)
2. Gnome/metacity failing to prevent some windows stealing focus

Thomas: they should only if you haven't selected or started typing in another window in the mean time (which happens all the time on slower computers when you start programs such as openoffice).

Wouter, update-manager is not stealing focus, it's just starting synaptic which is an another software and there is not easy GNOME api to use a correct timestamp to indicate that was an user action when doing that rather

Thomas, applications slow to start should never still the focus no, the idea of the focus prevention is to avoid getting in the user way no? When you use the application menu, click on an item and wait to get it open it'll get the focus which is right. Now if you start openoffice which takes 15 seconds to start, get an jabber message while waiting and start replying openoffice should go to the background rather than stopping you in whatever you are doing, no?

Wouter: I still don't have a concrete understanding of what "in the meantime" means. Clearly you mean that if focus hasn't changed, and no keyboard activity has occured, between time A and time B, the new window should not get focus. Time B is presumably the time when the window appears on the screen. What is time A? Is it "launch" in the sense of [1]? If so, you realise that that doesn't apply in the "sleep 8; gtk-demo" case given above? What should be done in that case?

[1] http://standards.freedesktop.org/startup-notification-spec/startup-notification-latest.txt

Thomas: starting new applications is almost simple:

If I use the panel to open an application, say OpenOffice, then after my click nothing should have focus,* because last click was on the panel's menu window, which doesn't exist anymore. So, if I don't give the focus to anything (e.g., by clicking in a window, or using alt-tab), then the newly created window should receive it (it's not stealing, since no one has it). If I do give some window the focus before the new one has a chance to receive it, then it shouldn't be stolen.

(* Note that this isn't exactly so: somehow the last window used before the panel gets focus when the panel closes, I'm not sure how.)

Starting things in other ways (e.g., when opening a file from Nautilus or Firefox, or using a global shortcut), is a tiny step beyond that, since an app. keeps having focus. My opinion is that if I use the focus in any way** after giving the command that opens a window, then the window shouldn't receive it. If I don't use the focus, than it means I'm waiting for the new window, so it should get its focus.

(** Use focus means either changing the widget that has focus, or acting on a widget. The only thing I can think of that isn't included is moving the mouse, but some unusual input methods may have more. Gestures, for instance. I _think_ if you replace 'widget' with 'window'—Metacity doesn't normally know what a window contains—you get a very good approximation of perfect behavior.)

AFAIK the above rules should be enough*** to provide very good user interaction for pretty much window creation (in fact, applications should do it for all _their_ windows, except if they're modal). The only thing missing is what happens if the initial focus is on the desktop, but I think the above is already hard enough to worry about this.

(*** As long as there's a _good_ type of notification for "waiting" applications. Flashing the task-bar isn't enough; for example, I don't have one on this computer, and I have it hidden on my other machine.)

=====

In short, if the user doesn't take any action (other than moving the mouse) between the moment a "command is given" and the moment that command "opens a window", then the new window should receive focus. Otherwise, it shouldn't be focused (unless it's modal, of course) and shouldn't be above the focused window (unless it's modal, of course; don't laugh, I've seen it happen).

I'm not sure if a window manager can find out the command that resulted in opening a window. But (1) if the new window belongs to the same process, then the window manager doesn't care, does it? And (2) if the new window belongs to a new process, I think you can use its process creation time as a good approximation of that point. (The mouse listener or whatever that creates a process is probably quick; it's loading all the data and building a window that's slow, which all happens after the process is created.)

"last click was on the panel's menu window, which doesn't exist anymore"

That isn't the way menus work, though; you can see this with the menus of any application. The case you mention in your first footnote is in fact the general case for all menus-- they always give focus back to where it came from. Anyway, we generally try not to have cases where *nothing* has focus. It makes the keyboard rather useless and confuses accessibility.

For what it's worth, if you open the new application with the panel menus, we do know the launch time because of the startup-notification system.

It's an interesting idea to use process creation time as point "A". Note, though, that it's not windows belonging to the same kernel process as such but windows which are marked in X as belonging with one another; you could imagine having one Java virtual machine process for the whole system running several applications.

I will think and confer and consider the other points.

Okay I just wanted to chime in and add that I also experience this with Compiz in Hardy. It steals focus not once but at least twice, if not three times. It is extremely perturbing to work when updating :[

I experience in Hardy, no compiz. It is very annoying, because I have the "normal" desktop effects enabled, which is generally stable on my system, but my processor is an Athlon XP, so when I'm multi-tasking (as always), it makes my music skip, text is slow, it just eats up my CPU until it can turn the screen half-black and white, then go back, then repeat, etc.

On Tue, Apr 8, 2008 at 6:45 PM, dbsoundman <email address hidden> wrote:

> I experience in Hardy, no compiz. It is very annoying, because I have
> the "normal" desktop effects enabled, which is generally stable on my
> system, but my processor is an Athlon XP, so when I'm multi-tasking (as
> always), it makes my music skip, text is slow, it just eats up my CPU
> until it can turn the screen half-black and white, then go back, then
> repeat, etc.
>

This sounds like general CPU/buffer problems, which may be bugworthy, but
this report is not that. This is about the windows stealing focus, "popping
up" in front of other things.

Thanks Andrew, I was citing the effects of the problem just as an example, the main issue is indeed just that the windows steal the focus. For me, that sets off that chain reaction, because of my not-so-fast processor. I would definitely like to see the "stealing focus" feature removed.

-Dan

On Tue, Apr 8, 2008 at 8:30 PM, dbsoundman <email address hidden> wrote:

> Thanks Andrew, I was citing the effects of the problem just as an
> example, the main issue is indeed just that the windows steal the focus.
> For me, that sets off that chain reaction, because of my not-so-fast
> processor. I would definitely like to see the "stealing focus" feature
> removed.
>

OK, sorry for the confusion. :)

This problem still exists in Hardy. Because of it, a kernel update got hosed up.

I fired off update-manager and switched to working on something else. While I was typing, a window popped up asking whether I wanted to change /boot/grub/menu.lst. The timing was such that I hit the spacebar just when the window popped up, so the window instantly disappeared, the updated kernel was installed, but the grub menu doesn't have an item for the new kernel. Without intervention on my part, this machine would end up keeping the old kernel until the next time the kernel was updated.

Fortunately, I know what happened and I know how to update the grub menu. However, my customers don't know about what's happening under the hood, and they shouldn't have to.

I'm astounded at how long this has been a problem. As mentioned by others, this should be a trivial fix. WTF?

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.net

This bug needs to be raised in importance and fixed. It hoses up systems, is easy to correct, and has been languishing for two years.

PLease don't assign to ubuntu-core-dev. Please.

This bug isn't easy to fix. And we invested a lot of time in finding a solution in update-manager/synaptic. But feel free to post a patch to this easy problem.

Daniel, unless you know of someone else to fix this, the maintainer of the package is the right person. In this case, the maintainer is ubuntu-core-dev.

Sebastien. Two solutions:
1. Remove every reference to grab_focus from:
./UpdateManager/Common/SimpleGladeApp.py, (I show lines 239 through 245) and
./UpdateManager/UpdateManager.py (I show lines 347 and 348)

See http://library.gnome.org/devel/pygtk/2.10/class-gtkwidget.html#method-gtkwidget--grab-focus

2. If that seems too draconian, in
./DistUpgrade/DistUpgrade.glade

set:
<property name="focus_on_map">False</property>

See http://www.pygtk.org/docs/pygtk/class-gdkwindow.html#method-gdkwindow--set-focus-on-map

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.net

Please don't assign to ubuntu-core-dev, really. It sends a mail to all core-devs (including those who don't work on update-manager...). Thanks.

On Tue, Dec 02, 2008 at 09:34:29PM -0000, Loye Young wrote:
> Daniel, unless you know of someone else to fix this, the maintainer of
> the package is the right person. In this case, the maintainer is ubuntu-
> core-dev.

I'm afraid that is not the right way to respond to this bug report. It is
already filed in the appropriate place, and the developers responsible for
this component are already aware of it by virtue of being bug contacts for
this package in Launchpad. There is no need to take any further action in
order to notify the appropriate people, and assigning bugs inappropriately
causes a nuisance. Please don't do it.

--
 - mdz

Argh! Please do NOT assign bugs to ubuntu-core-dev. The spam really isn't cool.

Launchpad team, please fix the bugs related to this (https://bugs.launchpad.net/bugs/299257), so this doesn't keep happening!

> Please don't assign to ubuntu-core-dev, really.

I meant to. Really.

> It sends a mail to all
>core-devs (including those who don't work on update-manager...).

That's a Good Thing (tm). I knew what I was doing and what the effects would be.

> There is no need to take any further action in
> order to notify the appropriate people,

The process must be broken, because this bug is two years old and
hasn't been assigned. The bug severity hasn't even been set (which,
IMHO, should be HIGH).

BTW, the problem isn't metacity. The problem is that update-manager
should not ask for focus in the first place. This is a problem that
has been solved over and over again in other applications.

>the developers responsible for
>this component are already aware of it by virtue of being bug contacts for
>this package in Launchpad.

That so? Hmmmm. . . . .So which of said "developers responsible" have
any idea how to turn off focus-stealing?

<off-topic>
If assigning the bug to ubuntu-core-dev is a Bad Thing (tm), perhaps
there should be a way to flag ubuntu-core-dev as a Wrong Person (tm)
and tell ubuntu_update-manager.assignee that the Wrong Person (tm)
cannot be a ValidAssignee.
</off-topic>

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.net

It already was assigned. mvo will be the one to fix it, whichever it actually happens to belong to.

On Tue, Dec 2, 2008 at 6:15 PM, Loye Young <email address hidden> wrote:

> BTW, the problem isn't metacity. The problem is that update-manager
> should not ask for focus in the first place. This is a problem that
> has been solved over and over again in other applications.

This is known already. See
https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/35876/comments/31and
https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/35876/comments/33.

2. If that seems too draconian, in
./DistUpgrade/DistUpgrade.glade

set:
<property name="focus_on_map">False</property>

See http://www.pygtk.org/docs/pygtk/class-gdkwindow.html#method-gdkwindow--set-focus-on-map

This solution doesn't work. Neither does setting "set_urgency_hint" = False in DistUpgrade/DistUpgrade.glade.

So far, I have not tested the other solution yet. If you minimise the app, it still throws the taskbar hint, but doesn't steal focus, incidently.

Solution 1 *sometimes* works, but I only remember this bug occurring sometimes anyway. So it probably isn't having an effect (as I'd guess that's only having an effect when the original update-manager window is getting created, which one tends to want in focus!)

Obviously, it's not a small, simple fix.

[banging head on desk]

Update-manager doesn't get focus randomly. It has to ask for it. The
window manager (metacity) just does what it's told to do. Anything the
window manager does to prevent focus-stealing is a sub-optimal
solution, but it's a necessary one when applications are written
egocentrically. (By this, I'm not talking about the developer's mental
health issues: we're all egocentric. An egocentric application means
an application written as if the application is either the only
application running or the most important application to the user at
the time)

"Obviously, it's not a small, simple fix."

Contrary to Sarah's assertion, setting "focus_on_map" to "false" in
every instance it appears in update-manager *fixes* update-manager:
Update-manager ceases to steal focus when that's done.

Here are the files affected:
./data/glade/UpdateManager.glade
./AutoUpgradeTester/DistUpgrade/DistUpgrade.glade
./DistUpgrade/DistUpgrade.glade
./debian/update-manager/usr/share/update-manager/glade/UpdateManager.glade
./debian/update-manager/usr/share/update-manager/glade/DistUpgrade.glade
./debian/tmp/usr/share/update-manager/glade/UpdateManager.glade
./debian/tmp/usr/share/update-manager/glade/DistUpgrade.glade

Unfortunately, it doesn't fix gkdebconf or debconf's frontends, which
ALSO have the same bug. Here's how to fix those:

gkdebconf (I'm using version 1.2.64ubuntu1 to test):
Insert the following line 101 in ./src/interface.c:
<code>
gtk_window_set_focus_on_map (GTK_WINDOW(win), FALSE);
</code>
and recompile.

debconf (I'm using version 1.5.20):
Insert the following line 70 to /usr/share/perl5/Debconf/FrontEnd/Gnome.pm:
<code>
$this->win->set_focus_on_map(0);
</code>
Fixing the other frontends (e.g., KDE) are left as an exercise.

Caveat: The changes to update-manager described above need to be fine
tuned. It's a Good Thing (tm) to allow the GtkWindow to get focus when
the user fires up Update-Manager the first time. I just didn't have
the patience to figure where in the code that is.

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.net

On Wed, Dec 10, 2008 at 7:02 PM, Loye Young <email address hidden> wrote:

> "Obviously, it's not a small, simple fix."
>
> Contrary to Sarah's assertion, setting "focus_on_map" to "false" in
> every instance it appears in update-manager *fixes* update-manager:
> Update-manager ceases to steal focus when that's done.

So could you provide a patch so others can test? Instructions here:
https://help.ubuntu.com/ubuntu/packagingguide/C/ubuntu-sync.html

> So could you provide a patch so others can test?

Somebody else will have to run with the ball on that.

On 12/11/2008 07:27 AM, Andrew Conkling wrote:
> On Wed, Dec 10, 2008 at 7:02 PM, Loye Young <email address hidden> wrote:
>
>> "Obviously, it's not a small, simple fix."
>>
>> Contrary to Sarah's assertion, setting "focus_on_map" to "false" in
>> every instance it appears in update-manager *fixes* update-manager:
>> Update-manager ceases to steal focus when that's done.
>
>
> So could you provide a patch so others can test? Instructions here:
> https://help.ubuntu.com/ubuntu/packagingguide/C/ubuntu-sync.html
>
Bug 306672 is about update-manager grabbing focus too often, By the
looks of this bug it doesn't grab focus unless told to?

--
Sincerely Yours,
    John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246

"How can i get lost, if i have no where to go"
    -- Metallica from UnforgivenIII

>Bug 306672 is about update-manager grabbing focus too often, By the
>looks of this bug it doesn't grab focus unless told to?

Not correct. Update-manager grabs focus inappropriately, and it needs
to be fixed.

Update-manager steals focus whenever it creates a window. The fix is
to change the focus_on_map setting to "false", as I have described.

In some circumstances, update-manager sends requests to gkdebconf and
other debconf frontends, which ALSO steal focus. I've described the
fix in a prior post. Gkdebconf and the debconf frontends are written
in different languages, so the syntax is different, but they share the
same solution: Tell those programs not to grab focus when it creates
the window.

To my knowledge, separate bugs have not been created for gkdebconf and
debconf to fix their problems, but I leave that to the "developers
responsible" that (according to some) are "already aware". I don't
want to be "uncool," even if I am just a hapless gringo in a Texas
border town. ;-)

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.net

So is this considered solved now by using the new notification system or is the behavior still the same?

Michael Vogt who is assigned to this bug has not posted in it since 2006.
Is he still around?

If he is, why doesn't he use the information provided by Loye Young in this bug to actually fix it?
I mean come on, it's a simple search and replace in six files and a one line addition to two other files.

I just tried it out in jaunty with the newest version of update-manager installed. The update-manager window still notifies the window manager, and in my case the window button in the task bar starts to blink, for example when the packages are downloaded and the installation starts.
Maybe this behavior is different on other window managers than compiz, which would bring the window to the front. But it is still annoying the way it behaves on my system.
As far as I know this has nothing to do with the new notification system at all, beause this is about applications sending notifications which are shown for a certain amount of time, but not for applications trying to gain focus.

This behavior is still present (and very annoying) in Intrepid with Xfwm4.

-H-

The task <-> assignee mapping here looks backwards to me.

Realistically I don't think we'll be able to generally fix this in metacity in Jaunty. I just corrected the upstream bug link for metacity, though.

Michael: For a local solution, do you think the progress window should just never receive focus? or at least focus_on_map false or so?

Behaviour still present in Karmic.

Would the assignee please apply the fix described in comment #55?

Benjamin: please be patient, this is not an easy fix, comment #55 does not have a patch or even a fix. If it is that important someone making a patch would be great. Comment #63 means that it needs to be discussed on what is the best way to handle the fix.

It needs to be discussed for four years?

I believe this bug was fixed in Update manager for metacity.

It no longer appears while using metacity as the WM, however , it does still happen when using compiz.
Also see similar bug but specific for compiz > Bug #391479

This bug has been fixed. Is anyone still facing this bug without compiz? Set the visual effect to none and check if it still steals focus, it doesnt here.
Michael Vogt mentioned he fixed this bug a long while ago.

This could be improved even further by making the window disappear when clicking "Install updates", doing the work in the background. The user really only needs to see the window if an error is encountered.

See solution #2
http://brainstorm.ubuntu.com/idea/24269/

I just tried with the fully updated lucid and this bug does not exist when my window manager is metacity i.e. when I disable desktop effects so I guess this is not an issue with metacity.

Omer , Thanks for comfirming.

As Mentioned earlier , this bug with metacity[no visual effects] has been fixed a while ago.

Users noticing this bug with compiz are affected by Bug #391479 .

This is NOT a bug in metacity, nor in compiz.

Almost two years ago, I described in this very thread what code should be
changed to fix the bug.

Loye Young
<email address hidden>
281-968-0828

On Wed, May 5, 2010 at 4:37 AM, Vish <email address hidden> wrote:

> Omer , Thanks for comfirming.
>
> As Mentioned earlier , this bug with metacity[no visual effects] has
> been fixed a while ago.
>
> Users noticing this bug with compiz are affected by Bug #391479 .
>
> ** Changed in: update-manager (Ubuntu)
> Status: Incomplete => Fix Released
>
> ** Changed in: hundredpapercuts
> Status: Incomplete => Invalid
>
> ** Changed in: metacity (Ubuntu)
> Status: Incomplete => Invalid
>
> ** Description changed:
>
> When I click the Reload button in update-manager, the "Downloading
> package information" progress dialog takes a few seconds to start, with
> the main window's widgets disabled. In this case, I switch to another
> application, and the download progress steals the window focus. If I
> switch again to another window, the "building dependency tree" progress
> dialog steals focus again.
>
> This is a bug in the metacity window manager.
> +
> + ***********
> + For users using metacity[no visual effects] this bug has been fixed a
> while ago.
> +
> + Users noticing this bug with compiz are affected by Bug #391479 .
> +
> + ***********
>
> --
> 'Downloading package information' and 'building dependency tree' progress
> dialogs request focus too often
> https://bugs.launchpad.net/bugs/35876
> You received this bug notification because you are a direct subscriber
> of the bug.
>

@Loye Young : This has been marked fixed in update-manager and invalid for metacity.
[The initial comments mention the bug being present with metacity as well which is now fixed in update manager, however it does still occur when compiz is the window manager Bug #391479 ]

Kindly provide a working patch , so that is can be tested and uploaded. [providing a patch could have probably solved the bug sooner than the time it took to write the arguments ]

I would suggest this is a dupe of #317370

https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/317370

This is fixed with changes in update-manager in Maverick, just FYI.

Is there a way to completely disable all applications/programs from stealing focus?
Cause it really-really-really annoys me!

Still an issue in Maverick, using xfwm4.