[window management] activating a link not switching to proper workspace

[Bill Filler]

Steps to reproduce:
1) run browser in workspace 1
2) run thunderbird or xchat in workspace 2
3) click on a link to a web page in thunderbird or xchat to open it
4) browser icon in launcher shakes but workspace is not switched to make it visible

this problem happens with both compiz and metacity as the WM. the problem does not happen when running docky or Unity GL with either of these window managers.

[Florian Boucault (fboucault)]

@Bill: "the problem does not happen when running [...] Unity GL with either of these window managers"

Unity GL is the window manager so I take that you are saying that the problem does not happen with Mutter. What I experience here is the same as described in the bug and that is with Compiz in a regular GNOME session (no Unity Qt). I believe this is an Ubuntu bug; I will look for a bug report.

[Bill Filler (bfiller)]

You're right. Upon retesting in regular Gnome Session with compiz I experience the same thing. I swear this used to work.. Oh well. We should still try to fix it if we can as it would make the entire user experience much nicer.

[Florian Boucault (fboucault)]

The default behaviour for chromium and firefox is to open a new tab in an existing browser window. If that window is on a different workspace then what you described happens. I am unsure if this is a good or bad thing from a user perspective. Two possible fixes could be implemented:
- either moving the browser window to the current workspace
- or moving the user to the workspace where the browser window is

I could not find any bug report in launchpad related to this.

[Bill Filler (bfiller)]

Moving the user to the workspace where the browser is would be desirable.

On Nov 25, 2010, at 12:24 AM, Florian Boucault <email address hidden> wrote:

> The default behaviour for chromium and firefox is to open a new tab in an existing browser window. If that window is on a different workspace then what you described happens. I am unsure if this is a good or bad thing from a user perspective. Two possible fixes could be implemented:
> - either moving the browser window to the current workspace
> - or moving the user to the workspace where the browser window is
>
> I could not find any bug report in launchpad related to this.
>
> --
> [windowmanagement] activating a link not switching to proper workspace
> https://bugs.launchpad.net/bugs/677216
> You received this bug notification because you are a member of The
> Upicek team, which is a direct subscriber.

[Florian Boucault (fboucault)]

Digging for bugs yield some interesting results.

Similar feature requests in awesome and openbox window managers:
- http://awesome.naquadah.org/bugs/index.php?do=details&task_id=848
- https://bugs.launchpad.net/ubuntu/+source/openbox/+bug/273574

The bug report that introduced the current behaviour for Firefox:
https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/175904

[Florian Boucault (fboucault)]

Great comment summarizing possible behaviours:

https://bugzilla.gnome.org/show_bug.cgi?id=482354#c52

[Florian Boucault (fboucault)]

Good policy written up by Patryk Zawadzki:

"""
* all automatic activations should result in a flashing taskbar
* all manual ("interactive") activations should result in the user seeing the
window (and moving the user to the window if necessary)
"""

[Florian Boucault (fboucault)]

Global summary of the issue:

Applications using gtk_window_present() (http://library.gnome.org/devel/gtk/unstable/GtkWindow.html#gtk-window-present) are broken because of Metacity/Compiz's response to _NET_ACTIVE_WINDOW (http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2550738). These window managers do _not_ show the window if it's on another workspace but instead set _NET_WM_STATE_DEMANDS_ATTENTION which results in the application flashing in the taskbar.

A number of applications are broken because of that:
- totem https://bugzilla.gnome.org/show_bug.cgi?id=470526
- nautilus (in spatial mode) https://bugzilla.gnome.org/show_bug.cgi?id=551367
- pidgin
- rhythmbox https://bugzilla.gnome.org/show_bug.cgi?id=587815

There is already a bug opened against metacity:
gtk_window.present() doesn't work if the window is already on another desktop https://bugs.edge.launchpad.net/ubuntu/+source/metacity/+bug/213432

[Florian Boucault (fboucault)]

Blog article by Metacity developer Thomas Thurman summarizing the issue from a user perspective: http://blogs.gnome.org/metacity/2008/07/22/dona-nobis-pacem/

[Florian Boucault (fboucault)]

@Bill: do you want us to patch Metacity and/or Compiz and solve these issues? Or should we lower the priority of that bug and deal with it later?

[Bill Filler (bfiller)]

going to lower priority and move to next milestone

[Olivier Tilloy (osomon)]

A direct consequence of this issue is bug #735205 (Alt tab does not switch to the desired application).

[Florian Boucault (fboucault)]

Similar to bug #772007