Turns out the online service was just a little slow to update, and there are in fact reports sent. But the only one post-20.04-upgrade is [1] from last week, which is a gnome-shell crash and IIRC, unrelated to the terminal issue here. It seemed to be triggered by something related to media files and Nautilus, and the logs from the time are different; I’m attaching them here. (I had separated gnome-shell logs out from the main syslog, but I’ve since reverted back to having everything in syslog.)
* [1] https://errors.ubuntu.com/oops/26828e26-8fc9-11ea-acd0-fa163e983629
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)
- 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)
- close Firefox
- open Nautilus, make sure that the window floats (i.e. is unmaximized and not tiled to either side of screen)
- 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)
- 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)
- close Firefox
- open Nautilus, maximize its window
- 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.
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
This does indeed seem to be fixed Vivid. Nautilus now has two options to remember the credentials (till logout or forever), and both seem to do what it says on the tin.
Also affects 12.04 (with gedit 3.4.1-0ubuntu1).
When the selected/renamed file is a directory: see Bug #1105232.
Apparently this is now supported; at least the following seems to work under 12.04:
$ qdbus org.gnome.Nautilus /org/gnome/Nautilus org.gnome.Nautilus.FileOperations.CopyFile "file:///source/directory" "*" "file:///destination/directory" ""
where /source/directory is the absolute path to your source directory, * is the glob for file[s] to copy,/destination/directory is your destination directory and the last ”” is for destination file name. Note that you need to have the last one there even if it’s empty as in here, to fulfill the method signature. Also, if you specify a target name and have multiple source files, they’ll all get copied to that one destination file, giving an overwrite prompt for each file after the first one (which may or may not be what you want).
I reported this on Launchpad [1] and was forwarded upstream.
Steps to reproduce:
1. touch ~/foo_åäö
2. In Nautilus, point at the file created in step 1
3. Right-click for context menu
4. Select Move to Trash
5. Press Ctrl-Z/Select Undo from the Edit menu
What happens:
Nothing
What I expect to happen:
For the file to recover from trash to ~.
What works:
* Undoing Move to Trash with files with no scandinavian letters in their path/filename.
* Recovering foo_åäö by opening Trash and selecting Recover from context menu.
More info:
* Could be that more characters, perhaps all non-ASCII characters render Nautilus’ Undo impotent — I’ve only tested å, ä and ö.
* The Finnish translation for Desktop (~/Desktop) is Työpöytä, which means files moved to trash from Desktop can’t be recovered. Nasty.
*[1] https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/973620
Steps to reproduce:
1. touch ~/foo_åäö
2. In Nautilus, point at the file created in step 1
3. Right-click for context menu
4. Select Move to Trash
5. Press Ctrl-Z/Select Undo from the Edit menu
What happens:
Nothing
What I expect to happen:
For the file to recover from trash to ~.
What works:
* Undoing Move to Trash with files with no scandinavian letters in their path/filename.
* Recovering foo_åäö by opening Trash and selecting Recover from context menu.
More info:
* Could be that more characters, perhaps all non-ASCII characters render Nautilus’ Undo impotent — I’ve only tested å, ä and ö.
* The Finnish translation for Desktop (~/Desktop) is Työpöytä, which means files moved to trash from Desktop can’t be recovered. Nasty.