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

Reported by Bill Filler on 2010-11-18
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Unity Distro Priority
Undecided
Unassigned
unity-2d
Medium
Unassigned
unity-2d (Ubuntu)
Undecided
Unassigned

Bug Description

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.

Bill Filler (bfiller) on 2010-11-18
Changed in upicek:
milestone: none → m3
importance: Undecided → High
Bill Filler (bfiller) on 2010-11-19
Changed in upicek:
importance: High → Medium
Bill Filler (bfiller) on 2010-11-19
Changed in upicek:
importance: Medium → High
assignee: nobody → Florian Boucault (fboucault)
status: New → Confirmed
Bill Filler (bfiller) on 2010-11-19
summary: - activating a link not switching to proper workspace
+ [windowmanagement] activating a link not switching to proper workspace

@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) wrote :

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) 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.

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.

Changed in upicek:
status: Confirmed → In Progress

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) wrote :

Great comment summarizing possible behaviours:

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

Florian Boucault (fboucault) wrote :

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) wrote :

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) wrote :

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) wrote :

@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) wrote :

going to lower priority and move to next milestone

Changed in upicek:
milestone: m3 → m4
importance: High → Medium
Changed in upicek:
status: In Progress → Triaged
status: Triaged → Confirmed
summary: - [windowmanagement] activating a link not switching to proper workspace
+ [window management] activating a link not switching to proper workspace
affects: upicek → unity-2d
Changed in unity-2d:
milestone: 0.4 → none
milestone: none → 3.4
visibility: private → public
Bill Filler (bfiller) on 2011-01-21
Changed in unity-2d:
milestone: 3.4 → none
Changed in unity-2d:
assignee: Florian Boucault (fboucault) → nobody
Olivier Tilloy (osomon) wrote :

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

Florian Boucault (fboucault) wrote :

Similar to bug #772007

Didier Roche (didrocks) on 2011-05-31
Changed in unity-2d (Ubuntu):
status: New → Confirmed
Didier Roche (didrocks) on 2012-01-18
Changed in unity-distro-priority:
status: New → Fix Committed
Tim Penhey (thumper) on 2012-02-20
tags: added: distro-priority
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.