Unplugging an external monitor causes windows to move to different workspaces

[notartom]

(1) Issue/Bug Description:

On a laptop, unplugging (yes, only unplugging) a second monitor causes all open windows to move to different workspaces.

(2) Steps to reproduce (if you know):

1. Have 9 static workspaces (I don't think the exact number matters, in fact I'm not even sure that static workspaces are needed to trigger this).
2. Have the laptop plugged into a Thunderbolt dock that has a second screen. I would assume just a second screen without the dock would also cause this.
3. Have Firefox open in workspace 8, and Hexchat on workspace 9. These are obviously examples.
4. Unplug the screen/dock.
5. Observe as Firefox moves to workspace 1, and Hexchat to workspace 2.

(3) Expected behavior:

Firefox and Hexchat remain on workspaces 8 and 9 respectively.

(4) Distribution (run cat /etc/os-release):

$ cat /etc/redhat-release 
Fedora release 33 (Thirty Three)

(5) Gnome Shell version:

3.38.5

(6) Pop Shell version (run apt policy pop-shell or provide the latest commit if building locally):

$ sudo dnf info gnome-shell-extension-pop-shell
Last metadata expiration check: 3:26:50 ago on Tue 30 Mar 2021 06:14:13 AM.
Installed Packages
Name         : gnome-shell-extension-pop-shell
Version      : 1.2.0
Release      : 3.fc33
Architecture : noarch
Size         : 1.0 M
Source       : gnome-shell-extension-pop-shell-1.2.0-3.fc33.src.rpm
Repository   : @System
From repo    : updates

(Although in Extentions Pop Shell is listed as Version 2)

(7) Where was Pop Shell installed from:

See above :)

(8) Monitor Setup (2 x 1080p, 4K, Primary(Horizontal), Secondary(Vertical), etc):

1920 x 1080 Thinkpad X1 6th gen screen, + external Asus 4K monitor.

(9) Other Installed/Enabled Extensions:

Sound Input & Output Device Chooser, Background Logo

(10) Other Notes:

[TLouf]

Thanks for reporting, same problem here, quite the hassle when moving offices for meetings and all your workspaces get messed up :/

(4) Distribution (run cat /etc/os-release): Pop!_OS 20.10

(5) Gnome Shell version: GNOME 3.38.3

(6) Pop Shell version (run apt policy pop-shell or provide the latest commit if building locally): Pop shell 1.1.0\~1619032486\~20.10~969e2c5

(7) Where was Pop Shell installed from: Preinstalled with the OS

(8) Monitor Setup (2 x 1080p, 4K, Primary(Horizontal), Secondary(Vertical), etc): Primary laptop monitor with secondary monitor in a vertical layout

(9) Other Installed/Enabled Extensions: Auto Move Windows, Dash to Dock, Workspaces Bar, Sound Input & Output Device Chooser

[wpietri]

Can confirm. This is especially maddening when a monitor is briefly unplugged. When I'm working, I'll have 4 workspaces configured with a total of circa 20 windows. If I bump a cable and the monitor is disconnected for a second, my windows will get scrambled madly. Stacks are unstacked, windows are placed chaotically. They should stay on the same workspaces with the same relative positions. And when the monitor is reconnected, they should return to their original location.

[MaxenceVacheron]

Same problem as wpietri. Annoying when I have to unplug my laptop to show something to a cowroker

[MarcusOlivecronaVC]

I have the same issue.

[tartley]

This happens to me several times every day, and is extremely maddening. For me, it's when an external monitor ('3' below) is switched between the Pop!_OS laptop and a gaming PC. On each switch, my laptop's window placement are scrambled onto different monitors and different workspaces.

When switching the monitor back to the laptop, window placements are just scrambled again, not restored to where they originally were.

Sometimes the scrambling results in an extra workspace being added. I currently have five workspaces, all created by this process. This happens even if I have disabled workspaces (ie set them to 1 static workspace).

$ cat /etc/os-release
NAME="Pop!_OS"
VERSION="22.04 LTS"
ID=pop
ID_LIKE="ubuntu debian"
PRETTY_NAME="Pop!_OS 22.04 LTS"
VERSION_ID="22.04"
HOME_URL="https://pop.system76.com"
SUPPORT_URL="https://support.system76.com"
BUG_REPORT_URL="https://github.com/pop-os/pop/issues"
PRIVACY_POLICY_URL="https://system76.com/privacy"
VERSION_CODENAME=jammy
UBUNTU_CODENAME=jammy
LOGO=distributor-logo-pop-os

(5) Gnome Shell version:

$ gnome-shell --version
GNOME Shell 42.5

(6) Pop Shell version (run apt policy pop-shell or provide the latest commit if building locally):

$ apt policy pop-shell
pop-shell:
  Installed: 1.1.0~1681999439~22.04~0e09473
  Candidate: 1.1.0~1681999439~22.04~0e09473
  Version table:
 *** 1.1.0~1681999439~22.04~0e09473 1001
       1001 http://apt.pop-os.org/release jammy/main amd64 Packages
       1001 http://apt.pop-os.org/release jammy/main i386 Packages
        100 /var/lib/dpkg/status

(7) Where was Pop Shell installed from:

Downloaded 22.04 LTS (NVIDIA) from https://pop.system76.com/ (to install on a new SSD I bought for an existing Pop!_OS System76 Gazelle laptop)

(8) Monitor Setup (2 x 1080p, 4K, Primary(Horizontal), Secondary(Vertical), etc):

[ 1 ][ 3 ][ 2 ]

1. Laptop display, 1080p (primary).
2. External monitor, 1080p, HDMI.
3. External monitor, 1080p, miniDisplayPort.

(9) Other Installed/Enabled Extensions:

gsettings get org.gnome.shell enabled-extensions | tr -d '[]' |  tr ' ' "\n" | sort
'cosmic-dock@system76.com',
'cosmic-workspaces@system76.com',
'ding@rastersoft.com',
'pop-cosmic@system76.com',
'pop-shell@system76.com',
'popx11gestures@system76.com'
'system76-power@system76.com',
'ubuntu-appindicators@ubuntu.com',

(No other extensions are installed, system-wide or per-user.)

[tartley]

I think the five issues above should be closed as dupes of this one.

Caveat: Some of those issues describe the problem occurring in response to more events than just monitor disconnection: User switching, enabling extensions, screen locking. It sounds like the same bug caused by several different circumstances, but I'm just guessing about that.

[tartley]

A workaround: If you know a monitor [dis]connection event is about to happen, then switch to non-tiling mode (Super-Y) while the monitor switch happens, then resume tiling (Super-Y again).

In my first experiments, this seems to put the windows in sensible places at every step of the process, and after first disconnecting and then re-connecting a monitor this way, windows end up back where they originally where.

Using this little dance, I haven't yet seen any new workspaces get created either.

[stocktonslack]

In my first experiments, this seems to put the windows in sensible places at every step of the process, and after first disconnecting and then re-connecting a monitor this way, windows end up back where they originally where.

I agree that the windows get put in sensible places, except for the fact that none of my stacks stay stacked - additionally when reconnecting to a monitor the windows don't end up back where they were (because they are no longer stacked)

[bmagyar]

Random placement would be fine with me I just don't get why new workspaces are being created on the fly...

[dkonigsberg]

I think I've recently been running into a related issue, that may very well have the same (or similar) root cause. (Commenting here because its where the trail of dupe-redirects ultimately lead.)

In my case, I'm generally not doing tiling or multiple workspaces. But I do switch between computers using a KVM. Ever since I switched to a HiDPI monitor (3840x2160 /w 125% scaling), this strange issue has cropped up.

I have a gnome-terminal window open on my screen, and every time I KVM-switch to/from the machine, the terminal window gets resized to become smaller. So whenever I switch back to the Pop system, I have to expand it again. Its possible other apps experience similar effects, but this is the one I most readily notice.

Once upon a time, I had a very similar sort of issue in the Windows world. The fix there was to find some deeply-hidden registry setting that controlled the resolution of the "virtual display" the desktop pretended it had whenever the monitor got unplugged, and adjust it to match the real display. I wonder if the cause/fix is similar here.

[nielsreijers]

+1, verrrry annoying

What should the correct behaviour be though? I think there are two options:

Workspaces are leading

The number of workspaces should stay the same.

• On disconnect: Windows on the disconnected screen move to the remaining screen in the same workspace. So if we have 4 workspaces before disconnecting, we have still 4 after, but with more windows.
• On (re)connect: it would be nice if a disconnect followed by a reconnect would restore the original state. In that case the windows should remember they belonged to a disconnected screen and move back. Alternatively, the workspaces on the new screen could just initially be empty.

Screen layout is leading

The layout of each screen should stay the same.

• On disconnect: the workspace screens on the disconnected monitor are moved to new workspaces on the remaining monitor and keep their layout, so if we have 4 workspaces before disconnecting, we have 8 after.
• On (re)connect: again it would be nice if disconnect/reconnect didn't change anything. For that to work each workspace would have to remember it was originally on a disconnected monitor. For example "Workspace 2" could have some extra state to remember it was originally "Workspace 1 on monitor X". Alternatively, again just empty workspaces on the new screen.

My personal preference would be the first since my screens are mostly single stacked windows. But I could imagine people who carefully layout windows on their screen might prefer the second.