Adding/Removing an external monitor causes open windows to move to another workspace

Reported by grigori on 2011-04-16
246
This bug affects 44 people
Affects Status Importance Assigned to Milestone
Compiz
Medium
Steve Langasek
0.9.9
Medium
Unassigned
Compiz Core
Medium
Christopher Townsend
compiz (Ubuntu)
Medium
Steve Langasek
Nominated for Precise by Christopher Townsend

Bug Description

[Impact]
Many users will put different windows in different workspaces for better work flow. If a user connects and/or disconnects an external monitor or projector, all of these windows will be put in the first workspace. Having to go back and move all of the windows back to their workspaces is very frustrating and time consuming.

[Test Case]
#. Open some applications in different workspaces.
#. Plug in an external monitor.

[Regression Potential]
Very low possibility that a window still ends up in the wrong workspace.

--------------------------------------------

Original description:
well, i plug in my external screen.

expected behaviour would be, if all of my windows would stay in the workspaces i aligned them to, and if they'd be on the same screen i had them in the first place.

unfortunatly in unity, if i plug-in (or plug-off) my external screen the windows are all around, but not where i'd expect them to be (namely in the same place they were before). so i always have to toggle expo-mode and re-align all of my windows.

Related branches

lp:~vorlon/compiz/lp.763148
Merged into lp:compiz/0.9.10 at revision 3646
PS Jenkins bot: Approve (continuous-integration) on 2013-04-07
MC Return: Abstain on 2013-04-07
Sam Spilsbury: Approve on 2013-04-07
lp:~vorlon/compiz/lp.763148-0.9.9
Merged into lp:compiz/0.9.9 at revision 3646
PS Jenkins bot: Approve (continuous-integration) on 2013-04-08
Didier Roche: Approve on 2013-04-08
Alex Launi (alexlauni) wrote :

The issue you're describing doesn't sound related to Unity. Could you log into a classic gnome session and see if this issue persists?

Changed in unity:
importance: Undecided → Low
status: New → Incomplete
Changed in compiz (Ubuntu):
status: New → Incomplete
Changed in unity (Ubuntu):
status: New → Incomplete
Changed in compiz (Ubuntu):
importance: Undecided → Low
Changed in unity (Ubuntu):
importance: Undecided → Low

you're absolutely right. i just tested it in classic-session. the problem was the same. so it seems to be a problem with compiz!?

btw. the windows are not "all around", as i said in the initial report; they rather seem to be aligned the way they were before i plugged in the secondary monitor, but without considering the 1080 pixels that are 'new' to the configuration. so a window that was on my second workspace in a one-monitor-layout, will appear on my first workspace in a two-monitor-layout, because it keeps the same distance to x=0/y=0 (which is the upper left corner) as before.

my way to "work around" this problem is to press "super+s" and drag the windows to the workspaces i have assigned them to before. doing this every time i change my monitor-layout is quite annoying.

Braiam Peguero (braiampe) wrote :

Can you disable compiz at all, using Gnome Classic (No effects), so we can confim as a compiz bug.

Changed in unity:
status: Incomplete → Invalid
Changed in unity (Ubuntu):
status: Incomplete → Invalid

just tested it: the bug does not occur after "metacity --replace" in gnome classic.

Changed in compiz (Ubuntu):
status: Incomplete → New
Changed in compiz (Ubuntu):
status: New → Confirmed
Bryce Harrington (bryce) wrote :

Reproduced problem on precise.

The new multi-monitor spec covers this case and describes what the proper behavior should be.

http://design.canonical.com/the-toolkit/unity-multi-monitor-interactions/

Changed in compiz (Ubuntu):
status: Confirmed → Triaged
importance: Low → Medium
Bryce Harrington (bryce) wrote :

Bumping priority up since current behavior is incorrect with respect to the specification.

tags: added: precise
summary: - multi-monitor setup breaks window/workspace alignment
+ Adding/Removing an external monitor causes open windows to move to
+ another workspace
affects: unity → compiz
Changed in compiz:
importance: Low → Medium
status: Invalid → Confirmed
milestone: none → 0.9.8.0
no longer affects: unity (Ubuntu)
Changed in compiz:
milestone: 0.9.8.0 → 0.9.8.1
Changed in compiz:
assignee: nobody → Ted Gould (ted)
Changed in compiz:
milestone: 0.9.8.2 → 0.9.8.4
Changed in compiz:
milestone: 0.9.8.4 → 0.9.9.0
Changed in compiz:
assignee: Ted Gould (ted) → nobody
Changed in compiz:
milestone: 0.9.9.0 → 0.9.9.2
Andy Freeland (rouge8) wrote :

Is there any information/logs needed to help resolve this bug? I can reproduce it every time.

Changed in compiz:
milestone: 0.9.9.2 → 0.9.10.0
Ian Hutchinson (hutch) wrote :

Thanks fo Daniel van Vugt for recurrent attention to this bug. But I presume his repeated changes to "milestone" mean that no one is paying the slightest attention to actually fixing it. Is there a realistic expectation that it will ever be fixed?

Ian Hutchinson: I'm not part of the team but I can say that there is an extremely small handful of people working on the compiz codebase - some of these people are also pulling double-duty on Mir. Unless a hero pulls off a set of patches to help the stack I'm afraid we're going to have to trust that they will prioritize the long bug list well enough to deal with the issues at the best time they can.

Hope that helps, and were I better at C++ I'd dive in myself.

Steve Langasek (vorlon) on 2013-04-07
Changed in compiz (Ubuntu):
status: Triaged → In Progress
assignee: nobody → Steve Langasek (vorlon)
PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:compiz at revision 3646, scheduled for release in compiz, milestone 0.9.10.0

Changed in compiz:
status: Confirmed → Fix Committed
Changed in compiz:
assignee: nobody → Steve Langasek (vorlon)
PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:compiz/0.9.9 at revision None, scheduled for release in compiz, milestone 0.9.9.2

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package compiz - 1:0.9.9~daily13.04.10-0ubuntu1

---------------
compiz (1:0.9.9~daily13.04.10-0ubuntu1) raring; urgency=low

  [ Steve Langasek ]
  * Adding/Removing an external monitor causes open windows to move to
    another workspace (LP: #763148)

  [ Ubuntu daily release ]
  * Automatic snapshot from revision 3646
 -- Ubuntu daily release <email address hidden> Wed, 10 Apr 2013 04:03:14 +0000

Changed in compiz (Ubuntu):
status: In Progress → Fix Released
Changed in compiz-core:
status: New → Confirmed
importance: Undecided → Medium
assignee: nobody → Christopher Townsend (townsend)

I'm going to work on backporting this fix to 12.04.

Changed in compiz-core:
status: Confirmed → In Progress
Daniel Farina (drfarina) wrote :

I filed #1166673 (a dupe) and can confirm that this update fixed my raring laptop. Yay.

Eduards Bezverhijs (edzis) wrote :

Terricif news! Thanks!
Now I'm looking into getting that on Precise...

Update:
I have a merge proposal in for lp:compiz-core which is the branch that is used for Precise. I'll work with the necessary folks to get this pushed through and get it out as an SRU.

Eduards Bezverhijs (edzis) wrote :

Hi!

I have tested this on precise, I've applied patch to current version of compiz, rebuilt packages and installed the following deb files:
sudo dpkg -i compiz_0.9.7.12-0ubuntu1_all.deb compiz-core_0.9.7.12-0ubuntu1_amd64.deb compiz-gnome_0.9.7.12-0ubuntu1_amd64.deb compiz-plugins_0.9.7.12-0ubuntu1_amd64.deb compiz-plugins-default_0.9.7.12-0ubuntu1_amd64.deb

I still see slightly incorrect behavior in case app is fullscreen on external display. So, when I maximize the app on external display, then remove the cable, space shrinks, window stays on the same workspace on primary screen maximized, that is expected and fine, but when I unmaximize it, it moves to the workspace on right, maybe it still thinks there is the space which was available when external display was connected. Maybe smht to do with original window position.

P.S. Really big thanks for the solution, now it at least do not mess up the whole WS when I connect projector or monitor.
P.P.S. As this is my "production" machine, I'll be testing this even more and will post the results.

Hi Eduards,

Thank you for trying out the patch for 12.04. I was wondering if you see the same slightly incorrect behavior in 13.04? I want to make sure my branch does not have some regression that is not present in 13.04.

Thanks!

Steve Langasek (vorlon) wrote :

Chris, yes, the behavior of full-screen windows is still wrong in 13.04.

Hi Steve,

Ok, thanks. I assume that should be a separate bug from this. Do you agree?

Steve Langasek (vorlon) wrote :

yeah, please treat that as a separate bug.

Eduards Bezverhijs (edzis) wrote :

Hi Christopher,

If you make another bug, please mention it here or please add me to the subscribers list.
Are You planning to fix it Yourself?
I'm asking because usually WS bugs are not going to be fixed anytime soon due to WS concept is thought as advanced feature for advanced users and therefore do not fall into the "for masses" category which means not a priority.

thanks
Eduards

Hi Eduards,

There are not any plans at this time to fix the WS issue you are seeing. However, since you are more familiar with the issue than I, could you please enter a new bug for this?

Thanks,
Chris

Eduards Bezverhijs (edzis) wrote :

Hi Chris,

Bug created https://bugs.launchpad.net/compiz/+bug/1171878
Added more details how to reproduce.

Thanks,
Eduards

Changed in compiz-core:
status: In Progress → Fix Committed
description: updated
description: updated
Margarita Manterola (marga-9) wrote :

I'm running precise. I installed the latest packages from https://launchpad.net/~unity-team/+archive/sru and I still have the same issue (turning off the right monitor causes the windows that were in that screen to move to a different workspace). So this is still not fixed in precise.

Hi Margarita,

That PPA does not contain the Precise version of the Compiz package that has this fix. It looks like this fix for inclusion into a package is still pending and it's hard to tell when that will happen.

Eduards Bezverhijs (edzis) wrote :

Hi!

I can share 0.9.7.12-0ubuntu1 packages for Precise (x86_64), if anyone interested.
Default disclaimer applies: packages are built by myself, works for me, otherwise use at own risk :)

regards
Eduards

Stephen M. Webb (bregma) on 2013-07-23
Changed in compiz:
status: Fix Committed → Fix Released
Mohamed Ragab (moragab) wrote :

Hi,

I am on 13.04 with the following compiz versions, this system was upgraded from 12.10 if that makes any difference

Package compiz:
i 1:0.9.10+13.10.20131011-0ubuntu1 saucy

Package compiz-core:
i 1:0.9.10+13.10.20131011-0ubuntu1 saucy

if the applications are *not maximized* they stay in their virtual desktop after connecting or disconnecting an external monitor

but the issue is still valid in case the applications are *maximized*, all maximized applications go to the first virtual desktop once an external monitor is connected or disconnected

Regards,
Mohamed

information type: Public → Public Security
information type: Public Security → Public

On Wed, Nov 20, 2013 at 09:32:06AM -0000, Mohamed Ragab wrote:

> but the issue is still valid in case the applications are *maximized*,
> all maximized applications go to the first virtual desktop once an
> external monitor is connected or disconnected

I believe there is a separate bug report open for this. And no, it's not
"the first virtual desktop", it's "the current virtual desktop".

Mark Russell (marrusl) wrote :

The fullscreen one is LP bug 1171878.

Ritesh Khadgaray (khadgaray) wrote :

Hi Mark

  I have posted a patch for this issue under bug 1171878. Let me know, if this helps.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related blueprints