thunar issueshttps://gitlab.xfce.org/xfce/thunar/-/issues2024-01-20T09:41:52Zhttps://gitlab.xfce.org/xfce/thunar/-/issues/1176Thunar suggesting to remove fixed DVD reader/writer2024-01-20T09:41:52ZGeorg SchwarzThunar suggesting to remove fixed DVD reader/writerSetup: freshly installed and updated Manjaro XFCE on a PC with built-in SATA DVD reader/writer.
Inserted DVDs show up on the Desktop (as it was configured to show them) as well as in Thunar (4.8.16) under "devices".
Now when selecting t...Setup: freshly installed and updated Manjaro XFCE on a PC with built-in SATA DVD reader/writer.
Inserted DVDs show up on the Desktop (as it was configured to show them) as well as in Thunar (4.8.16) under "devices".
Now when selecting the little triangle "eject" icon right next to the DVD's name on Thunar's left pane the DVD get's unmounted and ejected (as it shold).
However, I get the following desktop message
"Drive (DVD's title) is being unmounted. The Device is being ejected. This might take a while"
Then, once the DVD has been ejected:
"(DVD-reader/writer's model name) can be savely removed. The device can be unplugged."
This is a bit odd as it is a fixed device.
On the Desktop I can select "savely remove medium" (interestingly that has only an effect after I mounted the DVD, either explicitly or by double-clicking it). I then get the following desktop messages:
"Drive is being unmounted. The device (DVD's title) is being unmounted. This might take a while."
and then, once the DVD has been ejected:
"The device (DVD's title) has been safely removed."
I see the following issues here:
1. On the desktop selecting "savely remove medium" has no effect until the medium has been mounted (this is probably not related to Thunar)
2. Both Thunar's and the desktop's messages are referring to the DVD as a "drive" or "device". It should be referred to as a removable medium instead. The system does display its type as removable medium, so the system is aware that this is not a USB thumb drive, for example.
3. Thunar suggests that the DVD reader/writer could be unplugged. Maybe, just maybe, this might make sense for a USB DVD reader/writer (but even there I think it is unnecessary; why should empty USB DVD-ROMs not be unplugged at any time?). For a fixed reader it sounds pretty strange to the user.
I think a more consistent solution is possible.
(please do not mind the precise wording, as I am using a non-English installation)https://gitlab.xfce.org/xfce/thunar/-/issues/918Thunar (indirectly) does blocking D-Bus calls for every file in thunar_folder...2024-03-04T07:24:36ZErikaThunar (indirectly) does blocking D-Bus calls for every file in thunar_folder_finishedTested with thunar 4.16.11 (Xfce 4.16) packaged by Arch Linux.
I was switching between list and icon view with ctrl-1/ctrl-3 in a folder with ~150 files, and it took a noticeable amount of time (0.5sec). So I profiled thunar with perf a...Tested with thunar 4.16.11 (Xfce 4.16) packaged by Arch Linux.
I was switching between list and icon view with ctrl-1/ctrl-3 in a folder with ~150 files, and it took a noticeable amount of time (0.5sec). So I profiled thunar with perf and found that a lot of time was spent alternating between the main thread and dbus thread. The hot path on the main thread is:
```
thunar_folder_finished
thunar_file_reload
g_local_file_query_info
_g_local_file_info_get
g_daemon_vfs_local_file_add_info
meta_lookup_cache_lookup_path
get_tree_for_device
gvfs_metadata_call_get_tree_from_device_sync
g_dbus_proxy_call_sync
```
Everything between `_g_local_file_info_get` and `get_tree_for_device` supports passing a pointer to a cache for the most recent device queried, but the entrypoint g_local_file_query_info creates a fresh cache (GLocalParentFileInfo) every time. With `dbus-monitor` I confirmed that the query and reply are the same every time:
```
[... many more ...]
method return time=1666655820.862265 sender=:1.62 -> destination=:1.427 serial=50086 reply_serial=1865
string "uuid-86cd9bc4-d9fc-457d-a15c-798915671c62"
method call time=1666655820.862695 sender=:1.427 -> destination=:1.62 serial=1866 path=/org/gtk/vfs/metadata; interface=org.gtk.vfs.Metadata; member=GetTreeFromDevice
uint32 254
uint32 2
method return time=1666655820.863090 sender=:1.62 -> destination=:1.427 serial=50087 reply_serial=1866
string "uuid-86cd9bc4-d9fc-457d-a15c-798915671c62"
method call time=1666655820.863522 sender=:1.427 -> destination=:1.62 serial=1867 path=/org/gtk/vfs/metadata; interface=org.gtk.vfs.Metadata; member=GetTreeFromDevice
uint32 254
uint32 2
[... many more ...]
```
I also attached with gdb and used these breakpoints
```
(gdb) dprintf _g_local_file_info_get, "_g_local_file_info_get parent_info=%p parent_info->extra_data=%p\n", parent_info, parent_info->extra_data
(gdb) dprintf g_dbus_proxy_call_sync, "g_dbus_proxy_call_sync\n"
(gdb) dprintf thunar_folder_finished, "thunar_folder_finished\n"
(gdb) dprintf thunar_file_reload, "thunar_file_reload\n"
```
which gives a trace like
```
[... many cached requests not coming from thunar_folder_finished ...]
_g_local_file_info_get parent_info=0x7fffe800b5b8 parent_info->extra_data=0x7fffe806db20
_g_local_file_info_get parent_info=0x7fffe800b5b8 parent_info->extra_data=0x7fffe806db20
_g_local_file_info_get parent_info=0x7fffe800b5b8 parent_info->extra_data=0x7fffe806db20
_g_local_file_info_get parent_info=0x7fffe800b5b8 parent_info->extra_data=0x7fffe806db20
thunar_folder_finished
thunar_file_reload
_g_local_file_info_get parent_info=0x7fffffffde40 parent_info->extra_data=(nil)
g_dbus_proxy_call_sync
thunar_file_reload
_g_local_file_info_get parent_info=0x7fffffffde40 parent_info->extra_data=(nil)
g_dbus_proxy_call_sync
thunar_file_reload
_g_local_file_info_get parent_info=0x7fffffffde40 parent_info->extra_data=(nil)
g_dbus_proxy_call_sync
thunar_file_reload
_g_local_file_info_get parent_info=0x7fffffffde40 parent_info->extra_data=(nil)
g_dbus_proxy_call_sync
[... many uncached requests ...]
```
Though the issue is in gio/gvfs, it might be possible to side-step this in thunar (by calling g_local_file_query_info less?). I don't know the APIs well enough to say.https://gitlab.xfce.org/xfce/thunar/-/issues/446NFS share location not properly handled in pathbar2021-01-14T16:36:03ZTheo LinkspfeiferNFS share location not properly handled in pathbarThe location `nfs://localhost/srv/nfsshare` is displayed as `File System > srv > nfsshare`, but only the last part `nfsshare` is the mount point which can be accessed.
Expected result:
`nfsshare on localhost`
Version: 4.15.3The location `nfs://localhost/srv/nfsshare` is displayed as `File System > srv > nfsshare`, but only the last part `nfsshare` is the mount point which can be accessed.
Expected result:
`nfsshare on localhost`
Version: 4.15.3https://gitlab.xfce.org/xfce/thunar/-/issues/318View not updated when grandparent directory is trashed2021-04-06T09:34:33ZAlexander SchwinnView not updated when grandparent directory is trashedSteps to reproduce:
* mkdir -p a/b;touch a/b/somefile
* Open two thunar windows, on current folder and in b
* right-click on a --> move to trash (or `trash a` via console )
Result: "somefile" will still be shown.
Note that for trashi...Steps to reproduce:
* mkdir -p a/b;touch a/b/somefile
* Open two thunar windows, on current folder and in b
* right-click on a --> move to trash (or `trash a` via console )
Result: "somefile" will still be shown.
Note that for trashing the direct parent, things work fine
Note that for "delete", this bug does not existhttps://gitlab.xfce.org/xfce/thunar/-/issues/311Focus on left pane should not jump on right-click (keep focus in sync with di...2021-08-28T11:09:22ZAlexander SchwinnFocus on left pane should not jump on right-click (keep focus in sync with displayed folder)* Focus on left pane should stay on displayed folder, e.g. when ejecting a drive, instead of jumping somewhere else
Steps to reproduce:
1. open Desktop folder in thunar (focus is on the Desktop folder)
1. insert a flash drive and await...* Focus on left pane should stay on displayed folder, e.g. when ejecting a drive, instead of jumping somewhere else
Steps to reproduce:
1. open Desktop folder in thunar (focus is on the Desktop folder)
1. insert a flash drive and await for it to mount
1. right-click on the flash drive (focus then on flash drive) and select eject
1. flash drive ejected and focus moves to the next the entry below it (tree view), or is lost (bookmark view)
Expected:
* On right click provide some visual effect, but do not move the focus
* Tree-view and bookmark view should behave the samehttps://gitlab.xfce.org/xfce/thunar/-/issues/281Partially written files sometimes prematurely have thumbnails generated2022-01-07T13:51:16ZBugzilla MigrationPartially written files sometimes prematurely have thumbnails generated## Submitted by ykui
Assigned to **Xfce Bug Triage**
**[Link to original bug (#16467)](https://bugzilla.xfce.org/show_bug.cgi?id=16467)**
## Description
Created attachment 9484
Script for generating 100 images with random noise (t...## Submitted by ykui
Assigned to **Xfce Bug Triage**
**[Link to original bug (#16467)](https://bugzilla.xfce.org/show_bug.cgi?id=16467)**
## Description
Created attachment 9484
Script for generating 100 images with random noise (to generate thumbnails for)
Sometimes, particularly when many files are saved quickly, having Thunar open in the same directory causes some thumbnails to be generated before the file is finished writing.
This results in the thumbnail having a section of grey rows at the bottom.
Refreshing or navigating away and back does not cause the thumbnails to be regenerated (for the changed, completely written file).
The issue is somewhat reproducible with the attached script, while having Thunar navigated to the same directory.
**Attachment 9484**, "Script for generating 100 images with random noise (to generate thumbnails for)":
[file_16467.txt](/uploads/9b9b76736ee03bcbe1c0f012e565c882/file_16467.txt)
Version: 1.8.12https://gitlab.xfce.org/xfce/thunar/-/issues/272Incorrect files selection and incorrect thumbnails after drag & drop2023-04-29T10:03:53ZBugzilla MigrationIncorrect files selection and incorrect thumbnails after drag & drop## Submitted by Alexander Kurakin
Assigned to **Xfce Bug Triage**
**[Link to original bug (#16149)](https://bugzilla.xfce.org/show_bug.cgi?id=16149)**
## Description
Created attachment 9216
invalid selection
1. Open folder A in T...## Submitted by Alexander Kurakin
Assigned to **Xfce Bug Triage**
**[Link to original bug (#16149)](https://bugzilla.xfce.org/show_bug.cgi?id=16149)**
## Description
Created attachment 9216
invalid selection
1. Open folder A in Thunar tab
2. Open folder B in Thunar tab
3. Select maaaaaaaaaany picture files in A tab
4. Drag & drop them from A to B
5. Switch tabs during move. Scroll B tab during move.
6. Wait until move. Switch to tab B.
7. Not all files are selected.
**Attachment 9216**, "invalid selection":
![invalid_selection](/uploads/fbda5559937af30f97b83728fecc39a1/invalid_selection.png)
Version: 1.8.10
### See also
* https://bugzilla.xfce.org/show_bug.cgi?id=14755
* https://bugzilla.xfce.org/show_bug.cgi?id=14753https://gitlab.xfce.org/xfce/thunar/-/issues/211Thunar sometimes mounts USB drives with root permission2024-01-14T13:06:21ZBugzilla MigrationThunar sometimes mounts USB drives with root permission## Submitted by cjdg
Assigned to **Xfce Bug Triage**
**[Link to original bug (#14719)](https://bugzilla.xfce.org/show_bug.cgi?id=14719)**
## Description
Using Ubuntu Studio 18.04 sometimes thunar opens thumbdrives and drives as re...## Submitted by cjdg
Assigned to **Xfce Bug Triage**
**[Link to original bug (#14719)](https://bugzilla.xfce.org/show_bug.cgi?id=14719)**
## Description
Using Ubuntu Studio 18.04 sometimes thunar opens thumbdrives and drives as read only, but they work fine using terminalhttps://gitlab.xfce.org/xfce/thunar/-/issues/103Unintentionally closing window when closing tabs2020-10-19T21:26:41ZBugzilla MigrationUnintentionally closing window when closing tabs## Submitted by can..@..le.org
Assigned to **Xfce Bug Triage**
**[Link to original bug (#11921)](https://bugzilla.xfce.org/show_bug.cgi?id=11921)**
## Description
Created attachment 6269
Patch to add 'Preserve Final Tab' option/be...## Submitted by can..@..le.org
Assigned to **Xfce Bug Triage**
**[Link to original bug (#11921)](https://bugzilla.xfce.org/show_bug.cgi?id=11921)**
## Description
Created attachment 6269
Patch to add 'Preserve Final Tab' option/behaviour
This is a very minor thing but this catches me out a lot when using Thunar, even though I know the behaviour (it also catches me out when using the Leo editor), and I end up closing the Thunar window unintentionally quite often.
Current behaviour is that Thunar will close the window upon closing the last tab, which is the same behaviour as a lot of other file managers (apparently. I only use Thunar, so I don't know personally).
In my opinion, "Close Tab" (Ctrl-W) should only close the tab if there is a tab to be closed (i.e. the tab bar is visible). Otherwise, closing the window is not what the user requested.
However, this would be a significant change in behaviour and would require those that wanted to keep the current behaviour to enable the "Always Show Tabs" (hidden?) option. This would be pretty unreasonable (along with the additional bug reports that Ctrl-W had suddenly "stopped working").
I've attached a proof-of-concept patch which adds a "Preserve Final Tab" preference (in "Behaviour"), which prevents Thunar from closing the last tab. It isn't ideal ("Tabs" frame is actually packed inside the "Middle Click" frame because vbox gets redefined by the "Middle Click" section..) but demonstrates the behaviour I want adding and shows I am willing to/can provide a patch to do so, if it would be acceptable for inclusion.
It may be better to just prompt the user ("Close window? Y/N") if an attempt to close the last tab is made. I'm okay with coding any solution that would be acceptable!
Please note that I don't code in C, nor have I ever used GTK, so the code may be rough and need cleaning up.
**Attachment 6269**, "Patch to add 'Preserve Final Tab' option/behaviour":
[pft.patch](/uploads/9c517d16e494e2e30e62f673c3b50b47/pft.patch)
Version: 1.6.9https://gitlab.xfce.org/xfce/thunar/-/issues/100Thunar displays false-negative read permission emblems on file systems using ...2020-10-19T21:34:00ZBugzilla MigrationThunar displays false-negative read permission emblems on file systems using ACLs; patch attached## Submitted by Martijn Dekker
Assigned to **Xfce Bug Triage**
**[Link to original bug (#11645)](https://bugzilla.xfce.org/show_bug.cgi?id=11645)**
## Description
Created attachment 6033
Patch: Filesystem-independent read permissi...## Submitted by Martijn Dekker
Assigned to **Xfce Bug Triage**
**[Link to original bug (#11645)](https://bugzilla.xfce.org/show_bug.cgi?id=11645)**
## Description
Created attachment 6033
Patch: Filesystem-independent read permission check for thunar-file.c
Bug:
On file systems that use access controls other than Unix permission bits, Thunar shows false-negative read permission emblems on icons (the big red X).
For instance, at $WORK we run a Linux ext4 file system that makes extensive use of POSIX ACLs, because classic Unix permission bits just won't do for our needs. Users running Thunar were continually seeing big X emblems on files and folders to which they did in fact have read access through an ACL. This rendered those emblems both meaningless and annoying.
Proposed fix:
The attached patch fixed this for us so accurate big-red-X emblems are shown. It replaces the read permission checking logic in thunar-file.c with a much simpler approach: try to fopen() the file for reading to see if we're allowed to read it. fopen() causes the operating system to perform a permission check according to whatever filesystem is in use. If there is no read access permission, the call fails with a NULL stream pointer, and the read access checking function returns false. If the call succeeds, the stream is immediately closed again, and the function returns true.
Performance considerations:
I have not noticed any performance penalty. No actual read operation is done by only calling fopen() and fclose(). We're only accessing a directory that we've just been accessing anyway, so any file system data needed would have already been cached in RAM by the time we get to this check.
File system integrity considerations:
File access timestamps are a potential concern with this method. According to my testing, file access timestamps on ext4 are not changed by calling fopen(path,"r") immediately followed by fclose(). This makes sense, as no actual read operation is done, so the file itself wouldn't be accessed, only its directory entry. Browsing special file systems (/dev, /proc, /sys) with my patched Thunar has also been working as expected. Further testing is needed to check if this holds for other file systems and operating systems.
Portability considerations:
This method offloads the actual permission check onto the operating system, and should therefore be filesystem-agnostic and OS-agnostic. This would increase the portability of Thunar.
The use of fopen() for reading on any kind of file, even directories, is consistent with the POSIX spec. See: http://pubs.opengroup.org/onlinepubs/9699919799/functions/fopen.html (the EISDIR error is only returned if the named file is a directory *and* mode requires write access).
Security considerations:
I can think of no possible security implications associated with executing fopen(path,"r") on a known-to-be-present file only to close the stream again, but that doesn't mean there aren't any.
**Attachment 6033**, "Patch: Filesystem-independent read permission check for thunar-file.c":
[filesys-indep-permcheck.diff](/uploads/3375f0d855d6276e348d14be8aef8ca4/filesys-indep-permcheck.diff)https://gitlab.xfce.org/xfce/thunar/-/issues/94Make thunar display recursive file size2022-10-09T07:49:42ZBugzilla MigrationMake thunar display recursive file size## Submitted by Alexander Schwinn `@alexxcons`
Assigned to **Xfce Bug Triage**
**[Link to original bug (#11524)](https://bugzilla.xfce.org/show_bug.cgi?id=11524)**
## Description
For me it would be nice to have the option to enabl...## Submitted by Alexander Schwinn `@alexxcons`
Assigned to **Xfce Bug Triage**
**[Link to original bug (#11524)](https://bugzilla.xfce.org/show_bug.cgi?id=11524)**
## Description
For me it would be nice to have the option to enable recursive file-size display in the default-view of thunar.
When searching why a bunch of nested folders needs so much disk-space, it's always a pain to "right-click-->properties" each single folder and its sub-folders to see the total size. ( As painful as using du + cd in the console )
For this use-case it would be much more convenient to directly see the total-size in the thunar default-view.
I am aware of the ext4 / inode problem ( circular file-system references) in which the size-checking would end up in a infinite loop, displaying "... checking file size" forever.
However I think this would be no problem. It's just a special-case and should be treat as that.
In any case, the attempt to display the total size ( which will succeed in 99% of the cases ) is more informative than always display the same 4.0 KB on each folder.
If you dont like the idea to have the recursive-file-size per default, we could add a flag in the thunar-preferences in order to enable it. ( Personally I would vote for having the feature as default )
If you agree with the idea, and weather it should be the default behavior, I would start the implementation and provide a patch.https://gitlab.xfce.org/xfce/thunar/-/issues/44Support XF86Back and Forward keys2024-03-04T16:45:15ZBugzilla MigrationSupport XF86Back and Forward keys## Submitted by Mike Massonnet
Assigned to **Jannis Pohlmann**
**[Link to original bug (#9378)](https://bugzilla.xfce.org/show_bug.cgi?id=9378)**
## Description
Hi,
I know Thunar has already a bunch of shortcut to browse a tree, ...## Submitted by Mike Massonnet
Assigned to **Jannis Pohlmann**
**[Link to original bug (#9378)](https://bugzilla.xfce.org/show_bug.cgi?id=9378)**
## Description
Hi,
I know Thunar has already a bunch of shortcut to browse a tree, but it would be nice to add XF86Back and XF86Forward to go back and forth.
Cheers,
Mikehttps://gitlab.xfce.org/xfce/thunar/-/issues/31Default setting for showing hidden files2020-10-18T09:01:31ZBugzilla MigrationDefault setting for showing hidden files## Submitted by Kevin Cox
Assigned to **Jannis Pohlmann**
**[Link to original bug (#7650)](https://bugzilla.xfce.org/show_bug.cgi?id=7650)**
## Description
Currently, Thunar restores the last setting for hidden files. I think it ...## Submitted by Kevin Cox
Assigned to **Jannis Pohlmann**
**[Link to original bug (#7650)](https://bugzilla.xfce.org/show_bug.cgi?id=7650)**
## Description
Currently, Thunar restores the last setting for hidden files. I think it is more intuitive that the user can pick a default setting and have that be used in every new window.
I believe that most people usually want to or don't want to see hidden files. I don't think it goes in streaks.https://gitlab.xfce.org/xfce/thunar/-/issues/27Nautilus-like mouseover audio preview2022-04-11T19:48:10ZBugzilla MigrationNautilus-like mouseover audio preview## Submitted by Connor Behan
Assigned to **Jannis Pohlmann**
**[Link to original bug (#7354)](https://bugzilla.xfce.org/show_bug.cgi?id=7354)**
## Description
Created attachment 3527
Gstreamer audio preview
I don't know if anyone...## Submitted by Connor Behan
Assigned to **Jannis Pohlmann**
**[Link to original bug (#7354)](https://bugzilla.xfce.org/show_bug.cgi?id=7354)**
## Description
Created attachment 3527
Gstreamer audio preview
I don't know if anyone has switched away from Thunar because of this and maybe it doesn't matter. Most open source devs are friendly and don't "compete" right? Even though I like Thunar better for most things, one feature in Nautilus that I have yet to see duplicated is the automatic preview of audio files.
This patch may be flaky but it took me awhile to get right. I think the audio preview is quite reliable. It uses a timer and motion-notify-events and it is careful not to interfere with existing clicking and dragging callbacks. The mouse cursor is changed with GDK and the file is played with Gstreamer. I'd be thrilled if you could work it into Thunar in some way.
~~**Attachment 3527**~~, "Gstreamer audio preview":
[preview.patch](/uploads/42a4ad528483e555e4298bbf7b74bb07/preview.patch)
Version: 1.4.0https://gitlab.xfce.org/xfce/thunar/-/issues/25thunar settings dialog not pluggable2023-08-05T08:19:39ZBugzilla Migrationthunar settings dialog not pluggable## Submitted by Yves-Alexis Perez
Assigned to **Jannis Pohlmann**
**[Link to original bug (#7332)](https://bugzilla.xfce.org/show_bug.cgi?id=7332)**
## Description
Running the thunar settings dialog from xfce4-settings-manager lea...## Submitted by Yves-Alexis Perez
Assigned to **Jannis Pohlmann**
**[Link to original bug (#7332)](https://bugzilla.xfce.org/show_bug.cgi?id=7332)**
## Description
Running the thunar settings dialog from xfce4-settings-manager leads to a new popup instead of an embedded one.
Version: 1.6.12https://gitlab.xfce.org/xfce/thunar/-/issues/19Show available disk space in sidepane2024-03-11T09:24:34ZBugzilla MigrationShow available disk space in sidepane## Submitted by ericwang
Assigned to **Jannis Pohlmann**
**[Link to original bug (#5901)](https://bugzilla.xfce.org/show_bug.cgi?id=5901)**
## Description
Created attachment 2625
Thunar enhancement for disk's space and other ...
...## Submitted by ericwang
Assigned to **Jannis Pohlmann**
**[Link to original bug (#5901)](https://bugzilla.xfce.org/show_bug.cgi?id=5901)**
## Description
Created attachment 2625
Thunar enhancement for disk's space and other ...
Hi all:
We have done some enhancement based on Thunar's version which I git from
"git://git.xfce.org/xfce/thunar" at 09,16 2009.
The enhancement is as following
1, can show the available disk space
2, can show the available space of the mounted removable device, and add an
"eject button" to unmount it.
3, show a notification once the removable device is removed unsafely
4, Auto-refresh the removable device once a copying operation done
These enhancement can make Thunar more user friendly, it is useful for some
computer newbies to use the Thunar, which has been verified in our project.
you can check the attach file : Thunar-enhancement-git-version-20090916.patch
**Patch 2625**, "Thunar enhancement for disk's space and other ...":
[Thunar-enhancement-git-version-20090916.patch](/uploads/e507d2a5276b8991aa60c8dceca5f9ef/Thunar-enhancement-git-version-20090916.patch)
Version: Migration to GIOhttps://gitlab.xfce.org/xfce/thunar/-/issues/9Space should only select a file not run it2023-07-23T16:30:09ZBugzilla MigrationSpace should only select a file not run it## Submitted by Andrew Smith
Assigned to **Jannis Pohlmann**
**[Link to original bug (#3536)](https://bugzilla.xfce.org/show_bug.cgi?id=3536)**
## Description
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.8.1.5) Geck...## Submitted by Andrew Smith
Assigned to **Jannis Pohlmann**
**[Link to original bug (#3536)](https://bugzilla.xfce.org/show_bug.cgi?id=3536)**
## Description
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5
Build Identifier:
It is very unusual and a bit confusing, but mostly just annoying that after pressing the spacebar to give an item focus the item is selected (which is what I want) but also executed (which I expect to have to press Enter to do).
This happens in all three types of views.
Reproducible: Always
Steps to Reproduce:
1. Single-click on a file once.
2. Click on some area of the file manager that's not associated with a file (white space).
3. Press space.
Actual Results:
File gets selected + it's executed (for lack of a better word).
Expected Results:
File gets selected and is not executed.
Version: 0.8.0