Thanks, I’ve now reported this at: https://gitlab.gnome.org/GNOME/gnome-shell/issues/287

Background

I’m using Ubuntu 18.04 with Gnome Shell 3.28.1, and was forwarded here from Launchpad, see bug #1767806 there.

The issue

When another window is maximized or tiled to the left side of the screen, re-opening an application whose window was previously tiled to the left side does not restore that windows’ previous position. Instead such windows open at varying distances from the dock, untiled.

Expected behavior

Steps to reproduce (with a newly created user)

1. open Firefox, drag the window to the left edge of the screen to tile it there (filling up the left half of horizontal screen space)
2. close Firefox
3. open Nautilus, make sure that the window floats (i.e. is unmaximized and not tiled to either side of screen)
4. open Firefox

What happens

As expected, Firefox’s window is tiled to the left edge of screen, immediately to the right side of the dock: screenshot.

Unexpected behavior

Steps to reproduce (with a newly created user)

1. open Firefox, drag the window to the left edge of the screen to tile it there (filling up the left half of horizontal screen space)
2. close Firefox
3. open Nautilus, maximize its window
4. open Firefox

What happens

Firefox’s window opens slightly to the right off the right edge of the dock (with a gap between the dock and the window): screenshot.

What I expect to happen

I expect Firefox’s window to be tiled to the left edge of screen, immediately to the right side of the dock, just as it did following the first recipe above.

Further information

• Either maximizing or tiling Nautilus’ window to the left edge of the screen (at step 3) triggers the issue. Tiling it to the right edge of the screen does not.
• Using Gnome Terminal instead of Nautilus triggers the issue just as well and I suspect any other application will, though I’ve only systematically tested these two so far.
• From battling with this in my daily use I also know that the distance of incorrectly restored windows from the dock varies: different applications open at different distances. The precise mechanics of this still elude me, though the distances do appear to be multiples of 25 pixels.

When another window is maximized or tiled to the left side of the screen, re-opening an application whose window was previously tiled to the left side does not restore that windows’ previous position. Instead such windows open at varying distances from the dock, untiled.

= Steps to see expected behavior (with a newly created user) =

1. open Firefox, drag the window to the left edge of the screen to tile it there (filling up the left half of horizontal screen space)
2. close Firefox
3. open Nautilus, make sure that the window floats (i.e. is unmaximized and not tiled to either side of screen)
4. open Firefox

== What happens ==
As expected, Firefox’s window is tiled to the left edge of screen, immediately to the right side of the dock.

= Steps to reproduce unexpected behavior (with a newly created user) =
1. open Firefox, drag the window to the left edge of the screen to tile it there (filling up the left half of horizontal screen space)
2. close Firefox
3. open Nautilus, *maximize its window*
4. open Firefox

== What happens ==
Firefox’s window opens slightly to the right off the right edge of the dock.

== What I expect to happen ==
I expect Firefox’s window to be tiled to the left edge of screen, immediately to the right from the dock, just as it did following the first recipe above.

= Further information =
Either maximizing or tiling Nautilus’ window to the left edge of the screen (at step #3) triggers the issue. Tiling it to the *right* edge of the screen does not.

Using Gnome Terminal instead of Nautilus triggers the issue just as well, I suspect any other application will though I’ve only systematically tested these two so far.

From battling with this in my daily use I also know that the distance of incorrectly restored windows from the dock varies: different applications open at different distances. The precise mechanics of this still elude me, though the distances do appear to be multiples of 25 pixels.

I’ve had this happen a couple of times now since upgrading to 18.04: soon (perhaps within a minute) after logging in, Gnome session ends abruptly and I’m thrown back to the login screen. IIRC, in both instances this occurred on the first login after boot, so it does not reoccur on the subsequent re-login, and not on every login (very rarely in fact), and for now I have no better steps to reproduce this other than ”boot, log in”.

Bug #1663839 (reported against 17.04) seems similar, as does bug #1731428 (reported against 17.10).

journalctl output during the issue:

Apr 16 07:00:30 saegusa gnome-session[4342]: gnome-session-binary[4342]: WARNING: Application ’org.gnome.SettingsDaemon.Color.desktop’ failed to register before timeout
Apr 16 07:00:30 saegusa gnome-session-binary[4342]: WARNING: Application ’org.gnome.SettingsDaemon.Color.desktop’ failed to register before timeout
Apr 16 07:00:30 saegusa gnome-session-binary[4342]: Unrecoverable failure in required component org.gnome.SettingsDaemon.Color.desktop
Apr 16 07:00:30 saegusa gnome-session[4342]: gnome-session-binary[4342]: CRITICAL: We failed, but the fail whale is dead. Sorry….
Apr 16 07:00:30 saegusa gnome-session-binary[4342]: CRITICAL: We failed, but the fail whale is dead. Sorry….

Possible duplicates with bug #1607919

== Steps to reproduce ==
1. Create a password protected 7z archive: `echo hello >hello.txt; 7z a hello.7z hello.txt -ppassword`
2. Left-click the archive in Nautilus

== What happens ==
Nautilus shows an empty window, and together with gnome-shell they eat up the CPU until you close the Nautilus window. Alternatively, a crash report prompt appears.

== What I expect to happen ==
Preferably to prompt for a password and then open the archive contents. At the very least to not eat all the CPU, and inform the user that Nautilus is incapable of handling this file format.

== Other info ==
I don’t have Dropbox installed unlike in bug #1734891.

Upstream issue: https://gitlab.gnome.org/GNOME/nautilus/issues/51

Red Hat issue: https://bugzilla.redhat.com/show_bug.cgi?id=1499401

Had been AFK for a couple of hours with the display turned off, came back and turned it on when this occurred.

I’ve redirected Gnome Shell related log entries away from my syslog so I’m attaching the separate log here.

Looks like you can still enter ’Print’ in dconf-editor for a custom action (/org/gnome/settings-daemon/plugins/media-keys/custom-keybindings/customN/binding), so at least there’s that.

It seems that PrintScreen is now bound to Gnome Settings Daemon, which is used to take screenshots instead of gnome-screenshot. Keyboard settings (in Gnome settings) still has a screenshot shortcuts section in the keyboard shortcut settings, but those too now only trigger Gnome Settings Daemon’s screenshot feature, not gnome-screenshot.

What’s worse, disabling those shortcuts does not allow for remapping PrintScreen back to gnome-screenshot using a custom shortcut, as pressing PrintScreen in the shortcut selector window still just triggers the GSD ’blink’ instead of registering PrintScreen as the new shortcut key for the custom command. Only the screenshot section’s pre-defined actions allow for PrintScreen to be grabbed. (At least that’s what it does here.)

When the screenshot shortcuts are disabled, nothing is apparently saved anywhere despite the blink effect. The ”Save a screenshot to Pictures” shortcut has to be defined for the screenshots to actually get saved, and then they will be unconditionally saved to $XDG_PICTURES_DIR: https://bugzilla.gnome.org/show_bug.cgi?id=699642

Was there a regression or is gtk-update-icon-cache now a hard dependency? I’m getting this in Ubuntu 16.04 (when using the PPA).

The following packages have unmet dependencies:
 gnome-gmail : Depends: gtk-update-icon-cache but it is not installable