Sebastien, I think this may be related to the patch applied to fix Bug #1085320: the Gnome folks have since reverted (at least parts of) it (see Gnome bug 688808 [1]) because it caused custom icons to be shown as thumbnails, hence the borders reported in this LP bug. I tested this by applying the changes in [2] to current Nautilus in Raring (1:3.6.3-0ubuntu16), and the borders around my customized icons went away. Also, though I didn’t test very extensively, this didn’t result in desktop files again having borders as originally reported in #1085320.

(The commit log entry of [2] refers to [3], but I think it should refer to [4] instead.)

*[1] https://bugzilla.gnome.org/show_bug.cgi?id=688808#short_desc_nonedit_display
*[2] https://git.gnome.org/browse/nautilus/commit/?h=gnome-3-6&id=f69e472263b0bf6e1cc60c0eeaf7874fc7931f8d
*[3] https://git.gnome.org/browse/nautilus/commit/?id=d9ef715ea11e92917414d5d7bddd4dd1487fac1b
*[4] https://git.gnome.org/browse/nautilus/commit/?h=gnome-3-6&id=6cde4c5a6d639c85df09b8992a307f91d6b056a6

At least for Ubuntu users, I recommend filing those bugs on Launchpad. The package maintainers are usually able to tell pretty quickly if the issue is an upstream one, in which case you then file it upstream (in Gnome’s bugzilla) and link the two reports (there’s built-in functionality in LP precisely for this purpose). When the distributor’s tracker is your first port of call, you won’t (usually) be bothering upstream unnecessarily with distro-specific issues.

In fact, I sometimes file bugs on LP even when I know the issue is an upstream one, and then just link the reports right away. This way other Ubuntu users, who can’t tell the difference and would file the bug on Launchpad anyway, are saved the trouble.

Not reproducible in current 12.10 with gdm 3.6.0-0ubuntu4, still reproducible in 12.04 with gdm 3.4.0-0ubuntu15.

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

I reported this on Launchpad [1] and was forwarded upstream.

Steps to reproduce:
1. In Nautilus, select Connect to Server
2. Enter ftp server address, select FTP (with login) as type
3. Enter credentials,
4. select ”Remember this password”
5. Connect.
6. Disconnect.
7. Do steps 1.-2. again with the same server.

What happens:
The User name and Password fields remain empty. You have to enter your credentials again if you want to connect.

What I expect to happen:
For the Password field (at the very least) be automatically filled when I enter the associated user name. Better yet, remember and suggest (as default) both the User name and Password used previously.

Alternatively, just use ~/.netrc if that’s available and has the credentials (see [2]).

* [1] https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/963061
* [2] https://bugs.launchpad.net/bugs/963042

More accurate upstream target; previous was fixed but didn’t fix the issue reported here.

This has been fixed upstream ages ago, how come the fix never made it to Ubuntu? I’m using up-to-date Precise and this is still an issue: scrollwheel still browses between pictures instead of panning the current picture.

Steps to reproduce:
0. Set up Chromium/Firefox to prompt when it’s not the default browser (e.g. for FF, set browser.shell.checkDefaultBrowser to true)
1. Create/save a file with .html extension
2. From Nautilus, open the file’s properties
3. On the Open With tab, select gedit as default application to open html files with
4. In System settings, select Details and verify that in Default Applications the Default Web Browser hasn’t changed
5. Start Chromium/Firefox

What happens:
The browser thinks it’s not the default browser anymore and prompts you to set it as such.

What I expect to happen:
For the browser to know it still is the default browser and not ask about it.

Has this happened before:
Doesn’t seem to apply to Lucid, so the bug occurs somewhere between 10.04…12.04.

Further info:
I’ll attach a screenshot demonstrating the above result.

I’m not at all sure whether I filed this against the right package, feel free to correct it.

I still don’t have a surefire recipe for reproducing this, but it seems especially prone to occur when I have multiple Gnome terminal windows open, or one with multiple tabs in it, in addition to other apps. I have a gut feeling it’s triggered 4/5 times by switching from something else into the set of Gnome terminal windows (with the mouse, via launcher).