GNOME issueshttps://gitlab.gnome.org/groups/GNOME/-/issues2024-03-28T16:38:39Zhttps://gitlab.gnome.org/GNOME/nautilus/-/issues/3374Nautilus 46 is 4x to 30x slower than Thunar to show folder items on HDDs on i...2024-03-28T16:38:39ZJeff FortinNautilus 46 is 4x to 30x slower than Thunar to show folder items on HDDs on initial loadThis is complementary (but apparently different) to issues #3062 and #3067. Here, search is not involved, and scrolling is not involved. It is purely about processing performance for _local_ folders with many items.
**Summary:** Nautilu...This is complementary (but apparently different) to issues #3062 and #3067. Here, search is not involved, and scrolling is not involved. It is purely about processing performance for _local_ folders with many items.
**Summary:** Nautilus is _much_ slower to show (and to an extent load) folders with hundreds/thousands of items, compared to XFCE's "Thunar" file manager. It seems to be in big part due to thumbnails attributes processing being expensive.
* Particularly on HDDs, and particularly on cold start (i.e. not visiting a folder you previously visited during the session)
* Even with thumbnails disabled (and thumbnails cache already fully generated)
* Even with subfolder counts disabled (or no subfolders present at all)
* Even with `noatime` in `/etc/fstab`
<details><summary>Click to expand: hardware and methodology used for these benchmarks</summary>
## Testing parameters
My two benchmark machines, both with roughly the same "Downloads" folder containing about 2000 items:
* My current desktop workstation, with a new/fast HDD
(I use that instead of a SSD to contain huge amounts of heavy data files), with Nautilus nightly flatpak, 24 GB of RAM, and a beefier CPU. Note that the nightly flatpak has broken thumbnails on that machine (and otherwise that machine's thumbnails has its thumbnails cache directory on a SSD, not the HDD)
* My previous desktop computer, with an old HDD and 5 GB of RAM, using native (RPM) Nautilus 46 from Fedora 40.
It where I ran sysprof; I used this slower computer to exhibit performance problems more clearly.
RAM usage remained under 2 GB used out of 5 GB at all times.
Both computers use the `ext4` filesystem with LUKS encryption. The fast-HDD computer has `noatime` in `/etc/fstab`, the older computer with the slower HDD does not have noatime (or anything similar) configured.
## Methodology
* Measuring Nautilus 46 vs Thunar's time to 1) start showing contents of the folder 2) complete any remaining processing
* I measured multiple times, with a stopwatch, and sysprof 46
* To ensure consistently reproducible measurements, I flushed the kernel's disk caches to ensure we're truly reading "cold" from the disk.
* I also measured "warm" times, but those are less relevant.
* GIO measurements using [this Python script](/uploads/3be73d102258c3371eaa43b86448c27d/khalid_benchmark_script.py) (but results are worse than real-world scenarios)
To flush disk caches each time, I use this trick (to be run as root):
```
sync && sync && echo 3 > /proc/sys/vm/drop_caches
```
</details>
---
## Summary comparison of load times (in seconds)
| With listview, thumbnails off, folders counts off | | Nautilus 46 | Thunar | GIO Py script "with thumbs" | GIO Py script "no thumbs" |
|---------------------------------------------------|---------------------------------------|-------------|--------|-----------------------------|---------------------------|
| Cold cache – old HDD, 1850 files, RPM | Time for initial view/items to appear | **32** | 1.2 | NA | NA |
| | Time for folder to be fully processed | **33** | 8.5 | 24.59 | 00.00071 |
| Warm cache - old HDD, 1850 files, RPM | Time for initial view/items to appear | 1.7 | 1.2 | NA | NA |
| | Time for folder to be fully processed | 2.0 | 1.4 | 00.37 | 00.00070 |
| Cold cache – new HDD, 2200 files, Flatpak | Time for initial view/items to appear | **7.5** | 1.2 | not tested | not tested |
| | Time for folder to be fully processed | 8.2 | 7.5 | not tested | not tested |
| Warm cache – new HDD, 2200 files, Flatpak | Time for initial view/items to appear | 1.7 | 0.4 | not tested | not tested |
| | Time for folder to be fully processed | 2.0 | 1.9 | not tested | not tested |
## Sysprof captures from the old HDD
These captures are with the thumbnails cache already fully generated beforehand, and thumbnails turned off entirely, to eliminate those from the equation.
Sysprof capture file: [Nautilus_46_listview_loading_a_2000_items_folder__after_completed_thumbnailing.tar.xz](/uploads/8699d6f606a012b1da11422f3ff5937d/Nautilus_46_listview_loading_a_2000_items_folder__after_completed_thumbnailing.tar.xz)
Flame graph of the first 90% part (where Nautilus shows nothing while processing the folder's files), excluding the actual view's graphical loading:
![Nautilus_46_listview_loading_a_2000_items_folder__after_completed_thumbnailing_-_flamegraph_of_the_IO_part_only__no_listview_painting_.opti](/uploads/9f2b669f2ea52e5dfeb435a6a3e0ab2d/Nautilus_46_listview_loading_a_2000_items_folder__after_completed_thumbnailing_-_flamegraph_of_the_IO_part_only__no_listview_painting_.opti.png)
<details><summary>Click to expand: Complete flame graph (including the view's painting after files have been processed)</summary>
![Nautilus_46_listview_loading_a_2000_items_folder__after_completed_thumbnailing_-_flamegraph_including_IO_and_listview_painting.opti](/uploads/555e9d450b462f34e43e6c0e21fffade/Nautilus_46_listview_loading_a_2000_items_folder__after_completed_thumbnailing_-_flamegraph_including_IO_and_listview_painting.opti.png)
</details>
Hard drive disk IO usage chart over time:
![Nautilus_46_listview_loading_a_2000_items_folder__after_completed_thumbnailing_-_disk_IO_graph.opti](/uploads/990aba00559699e46c67163252281391/Nautilus_46_listview_loading_a_2000_items_folder__after_completed_thumbnailing_-_disk_IO_graph.opti.png)
| iotop idle before loading the folder | iotop during loading, snapshot 1 | iotop during loading, snapshot 2 | iotop after folder is loaded |
| - | - | - | - |
| ![Nautilus_46_listview_loading_a_2000_items_folder__after_completed_thumbnails_-_iotop_1__before_loading_folder_.opti](/uploads/13c6a7752666670dbba9a4f13e8dcb64/Nautilus_46_listview_loading_a_2000_items_folder__after_completed_thumbnails_-_iotop_1__before_loading_folder_.opti.png) | ![Nautilus_46_listview_loading_a_2000_items_folder__after_completed_thumbnails_-_iotop_2.opti](/uploads/2b974587225d6878128c342ff3315524/Nautilus_46_listview_loading_a_2000_items_folder__after_completed_thumbnails_-_iotop_2.opti.png) | ![Nautilus_46_listview_loading_a_2000_items_folder__after_completed_thumbnails_-_iotop_3.opti](/uploads/b4fabc36b0a0b6e351988758a33e0448/Nautilus_46_listview_loading_a_2000_items_folder__after_completed_thumbnails_-_iotop_3.opti.png) | ![Nautilus_46_listview_loading_a_2000_items_folder__after_completed_thumbnails_-_iotop_4.opti](/uploads/885d6f2f5320d6671e2966a79fdc1bed/Nautilus_46_listview_loading_a_2000_items_folder__after_completed_thumbnails_-_iotop_4.opti.png) |
## Observations
* With a cold disk kernel cache, Thunar consistently loads any folder faster than Nautilus: **between 4x and 27x faster,** depending on how you look at it
* Thunar always starts displaying folder contents **within 1.2 seconds** (even if it's just the currently visible part of the view), and keeps processing the rest (if any) in the background. During that time, Nautilus does not even show a progressbar (which could at least help users wait more patiently, compared to a spinner)
* Based on what I heard from the hard drive's head during my tests, Thunar seems to grind the disk much less, while Nautilus seems to grind much more intensively and longer.
* According to the flamegraph, Nautilus spends most of its time processing thumbnail info, even when it doesn't strictly need to (if thumbnails are disabled). One could think we could just avoid touching thumbnails code in that case. _However:_
* even if Nautilus' "zoomed out listview" displays icons instead of thumbnails (via CSS), it's only a zoom-in away from needing to instantly display them… so that might not be a silver bullet;
* browsing "with thumbnails fully disabled" otherwise is kind of a niche usecase;
* Thunar manages to do all this _with_ thumbnails activated (even if it has to generate them), whereas Nautilus struggles even with thumbnails deactivated and hidden. Ideally we should figure out a way for Nautilus' `get_thumbnail_attributes` / `thumbnail_verify` to be fast instead, as it would presumably speed up Nautilus' views everywhere (including search).
Summary: overall, in terms of UX, a folder that Nautilus will take many seconds (or even minutes) before loading or starting to show contents, will feel "instantaneous" to load in Thunar, in part because it starts showing contents early, and in part because it seems to be more efficient, so presumably Nautilus is also doing extra work that it shouldn't be doing.https://gitlab.gnome.org/GNOME/nautilus/-/issues/3369DnD operations are inconsistently move/copy2024-03-25T23:08:05ZBart GravendeelDnD operations are inconsistently move/copy# Affected Version
- Version: 47.alpha
- Distribution: GNOME OS
- Also happens with development version: Yes
# Steps to reproduce
1. Grab a file
2. Drag it out of the current folder (i.e. via the navigation bar)
3. The drop operation is...# Affected Version
- Version: 47.alpha
- Distribution: GNOME OS
- Also happens with development version: Yes
# Steps to reproduce
1. Grab a file
2. Drag it out of the current folder (i.e. via the navigation bar)
3. The drop operation is either move or copy, but there is no consistent behavior here.
# Expected Behavior
For a consistent operation to be used, either move or copy.
# Actual Behavior
There is no consistency in the operation.
# Additional Information
![Screencast_from_2024-03-24_17-35-12](/uploads/3923cb2ae5bc09dfdc3888c2a92ed682/Screencast_from_2024-03-24_17-35-12.webm)https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1201Fast Scrolling is Slower than Slow Scrolling2024-03-16T16:28:38ZsnoutieFast Scrolling is Slower than Slow Scrolling<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
<!--
Provide at least the following information:
* Your OS an...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
<!--
Provide at least the following information:
* Your OS and version
* Affected GNOME Calendar version
-->
Fedora 39
GNOME Calendar 45.1
### Bug summary
<!--
Provide a short summary of the bug you encountered.
-->
When Scrolling through the calendar, fast scrolling will result in less area scrolled compared to slow scrolling in the same time.
This makes the app frustrating to use.
### Steps to reproduce
<!--
1. Step one
2. Step two
3. ...
-->
1. Scroll with a normal speed, as if you scrolled through a webpage, notice the view scrolling only by one line even though you scrolled an amount worth of more
2. Scroll slower, waiting for each animation cycle to finish before scrolling further, notice how now every scroll goes through
Or alternatively:
1. Place finger on scroll wheel
2. Scroll down fast
3. Scroll up slowly until your finger reaches the starting position again
4. Notice how the view is not at the starting position, but further up
### What happened
<!--
What did GNOME Calendar do that was unexpected?
-->
Fast Scrolling is slower than Slow Scrolling
### What did you expect to happen
<!--
What did you expect GNOME Calendar to do?
-->
Fast Scrolling is faster than Slow Scrolling
### Relevant logs, screenshots, screencasts etc.
<!--
If you have further information, such as technical documentation, logs,
screenshots or screencasts related, please provide them here.
If the bug is a crash, please obtain a stack trace with installed debug
symbols (at least for GNOME Calendar) and attach it to
this issue following the instructions on
https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces.
-->
![Screencast_from_2024-03-15_21-28-25](/uploads/4e0bf8c03e411d3b3bfb7bc5a998e199/Screencast_from_2024-03-15_21-28-25.webm)
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-music/-/issues/604Thousands of albums makes the program nearly unusable2024-03-14T09:16:48ZCaden MitchellThousands of albums makes the program nearly unusable## Description
The app is not optimized to be able to load thousands of albums efficiently. It constantly freezes and uses lots of CPU.
## Steps To Reproduce
- Add a few thousand audio files
- Give each file a unique album metadata an...## Description
The app is not optimized to be able to load thousands of albums efficiently. It constantly freezes and uses lots of CPU.
## Steps To Reproduce
- Add a few thousand audio files
- Give each file a unique album metadata and album art
- Place in Music folder and open Music
- Scroll down
## Expected Behaviour
App should run well.
## Actual Behaviour
App lags and freezes constantly. If the album list is still, it seems fairly responsive, but try to scroll, and it will majorly lag and freeze trying to load in the new album art, or possibly from trying to scroll thousands of GtkButtons? I don't know what the bottleneck is, but somehow other music apps can handle loads of albums efficiently.
## Specifications
Gnome Music Version: 45
Desktop Environment: GNOME
Wayland or Xorg: Wayland
Flatpak or Native: Flatpak
Tracker Version: ? (not in about dialog)
Grilo Version: ? (not in about dialogue)
## Additional Informationhttps://gitlab.gnome.org/GNOME/gnome-music/-/issues/603Feature request: Metadata loading status screen2024-03-14T08:45:50ZCaden MitchellFeature request: Metadata loading status screen## Description
When you suddenly introduce Music to thousands of songs while its running, it just kinda seizes up. I think it would be better if there were an AdwStatusPage with an animated spinner and a music icon or something, explain...## Description
When you suddenly introduce Music to thousands of songs while its running, it just kinda seizes up. I think it would be better if there were an AdwStatusPage with an animated spinner and a music icon or something, explaining that it is fetching resources like album art and metadata. There should also be a progress bar showing eg. 22/2,451 songs loaded, so the user gets some feedback on the software. Otherwise, the user may assume the app is frozen or broken, and they may not realize it is just operating normally.
Alternatively, something like Nautilus has, where there is a circle in the upper left corner showing progress, and some text saying "loading metadata". It's a button, and clicking it shows more specifics, like the exact progress, and maybe the current file it's working.
## Steps To Reproduce
- Link or paste thousands of songs with metadata into the Music folder while it is running
## Expected Behaviour
Status report of the metadata scanning operation
## Actual Behaviour
Appears to be frozen
## Specifications
Gnome Music Version: 45
Desktop Environment: GNOME
Wayland or Xorg: Wayland
Flatpak or Native: Flatpak
## Screenshot
![Screenshot from 2024-03-14 01-42-18.png](/uploads/4cee61c783eb847154b721228cb9cb06/Screenshot_from_2024-03-14_01-42-18.png)https://gitlab.gnome.org/GNOME/glib/-/issues/3288Uninitialized access in libcharset2024-03-25T10:20:56ZFederico Mena QuinteroUninitialized access in libcharsetI'm experimenting with meson's `-Db_sanitize=memory` option for libipuz, and I'm getting a bunch of these in the test suite:
```
Uninitialized bytes in __interceptor_fopen64 at offset 0 inside [0x702000000120, 25)
==7698==WARNING: Memor...I'm experimenting with meson's `-Db_sanitize=memory` option for libipuz, and I'm getting a bunch of these in the test suite:
```
Uninitialized bytes in __interceptor_fopen64 at offset 0 inside [0x702000000120, 25)
==7698==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x7fc71d505514 in _g_locale_get_charset_aliases /usr/src/debug/glib2-2.74.7-2.fc37.x86_64/redhat-linux-build/../glib/libcharset/localcharset.c:137:38
#1 0x7fc71d4934fd in _g_locale_get_charset_aliases /usr/src/debug/glib2-2.74.7-2.fc37.x86_64/redhat-linux-build/../glib/libcharset/localcharset.c:112:6
#2 0x7fc71d4934fd in _g_locale_charset_unalias /usr/src/debug/glib2-2.74.7-2.fc37.x86_64/redhat-linux-build/../glib/libcharset/localcharset.c:444:18
#3 0x7fc71d4934fd in g_utf8_get_charset_internal /usr/src/debug/glib2-2.74.7-2.fc37.x86_64/redhat-linux-build/../glib/gcharset.c:137:13
#4 0x7fc71d49371f in g_get_charset /usr/src/debug/glib2-2.74.7-2.fc37.x86_64/redhat-linux-build/../glib/gcharset.c:222:24
#5 0x7fc71d4bcdd5 /usr/src/debug/glib2-2.74.7-2.fc37.x86_64/redhat-linux-build/../glib/gmessages.c:3349:7
#6 0x7fc71d4c1251 in g_print /usr/src/debug/glib2-2.74.7-2.fc37.x86_64/redhat-linux-build/../glib/gmessages.c:3408:5
#7 0x7fc71d4db0e8 in g_test_log /usr/src/debug/glib2-2.74.7-2.fc37.x86_64/redhat-linux-build/../glib/gtestutils.c:996:9
#8 0x7fc71d4dc9c5 in g_test_init /usr/src/debug/glib2-2.74.7-2.fc37.x86_64/redhat-linux-build/../glib/gtestutils.c:1736:3
#9 0x4ad21a in main /srv/project/_build/../libipuz/tests/style.c:94:3
#10 0x7fc71d17d54f in __libc_start_call_main (/lib64/libc.so.6+0x2754f) (BuildId: 0dc6d3e329f8bf5e8c1de63c4c9d560fb9953ade)
#11 0x7fc71d17d608 in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x27608) (BuildId: 0dc6d3e329f8bf5e8c1de63c4c9d560fb9953ade)
#12 0x41e554 in _start (/srv/project/_build/libipuz/tests/style+0x41e554) (BuildId: c5515b1facc89f70df521d894b95ac080ab41af1)
SUMMARY: MemorySanitizer: use-of-uninitialized-value /usr/src/debug/glib2-2.74.7-2.fc37.x86_64/redhat-linux-build/../glib/libcharset/localcharset.c:137:38 in _g_locale_get_charset_aliases
```
Do you know what that's about?https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1197EDS' "Data source does not support OAuth 2.0 authentication" error sometimes ...2024-03-15T14:04:07ZMichael CatanzaroEDS' "Data source does not support OAuth 2.0 authentication" error sometimes prevents seeing any Google Apps for Enterprise calendarsI'm unable to access any of my Google calendars in gnome-calendar-46~beta-2.fc40. It's as if the calendars are just not there: GNOME Calendar does not display any warning or error message of any sort in the UI (#17). The Google account i...I'm unable to access any of my Google calendars in gnome-calendar-46~beta-2.fc40. It's as if the calendars are just not there: GNOME Calendar does not display any warning or error message of any sort in the UI (#17). The Google account is configured using gnome-online-accounts.
```
(gnome-calendar:39093): GcalManager-WARNING **: 10:19:39.553: source_credentials_required_cb: Failed to authenticate 'mcatanza@redhat.com': Data source “mcatanza@redhat.com” does not support OAuth 2.0 authentication
```
That's strange because this is Google, which surely does support OAuth 2.0.https://gitlab.gnome.org/GNOME/gimp/-/issues/11037Gaussian blur in Mac OS GIMP does not correctly blur the alpha channel2024-03-13T15:05:59ZAlexander ThomasGaussian blur in Mac OS GIMP does not correctly blur the alpha channel### Environment/Versions
- GIMP version: 2.10.36
- Package: Installer from gimp.org, also in MacPorts build
- Operating System: Mac OS Sonoma 14.3.1
### Description of the bug
Applying Gaussian Blur on a layer that has an Alpha channe...### Environment/Versions
- GIMP version: 2.10.36
- Package: Installer from gimp.org, also in MacPorts build
- Operating System: Mac OS Sonoma 14.3.1
### Description of the bug
Applying Gaussian Blur on a layer that has an Alpha channel, will not fully blur the alpha channel. The original un-blurred channel seems to be overlaid onto the blurred result.
### Reproduction
Is the bug reproducible? Always
Reproduction steps:
1. Open attached BlurTest.xcf file.[BlurTest.xcf](/uploads/7cf24b9ffe957a962be9d7a0a00b60a1/BlurTest.xcf)
2. Apply Gaussian Blur with radius 8 or greater.
3. Observe result.
Expected result:
The black and white regions are fully blurred. This is the result I get with GIMP 2.10.36 in Ubuntu installed through snap.
![Blurred-correct](/uploads/b61c9dbd2876ddd1ef7359a0621c4879/Blurred-correct.png)
Actual result:
The result I get in the Mac OS build, looks like the un-blurred image overlaid onto the blurred image. The 1-pixel wide details can still be discerned, which should be impossible with an 8-pixel radius blur.
![Blurred-MacGIMP](/uploads/b7c357b8bf59143a4af667f8d90888b6/Blurred-MacGIMP.png)
### Additional information
I don't seem to remember seeing this problem while I was using GIMP in Mac OS Ventura. I have tried reinstalling my entire MacPorts including GIMP, but the bug is still present. The other types of blur filters seem to work as expected.https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2950"Add a picture" does not check whether the selected picture(s) already are am...2024-03-10T23:37:33ZJeff Fortin"Add a picture" does not check whether the selected picture(s) already are among the wallpapers library, creates duplicates1. Add a couple of wallpapers to Settings' Appearance panel, with the "Add a picture" button
2. Click the "Add a picture" button again, and select one (or multiple) wallpaper(s), with some wallpapers that already have been added
Result:...1. Add a couple of wallpapers to Settings' Appearance panel, with the "Add a picture" button
2. Click the "Add a picture" button again, and select one (or multiple) wallpaper(s), with some wallpapers that already have been added
Result: duplicate entries are added to Settings' favorite wallpapers grid
Expected result:
* Do not add wallpapers that were already added
* If adding only one wallpaper, and that wallpaper would be a duplicate, select (apply) that wallpaper directly (as if the user had clicked it).https://gitlab.gnome.org/GNOME/nautilus/-/issues/3354Empty “” selected text after deleting a file2024-03-22T16:01:39ZAlessandro BonoEmpty “” selected text after deleting a file# Affected Version
- Version: NautilusDevel
- Distribution: Flatpak
- Also happens with development version: Yes
# Steps to reproduce <!-- Explain in detail how the issue can be reproduced. -->
1. Select a file
2. Press Delete
# Expect...# Affected Version
- Version: NautilusDevel
- Distribution: Flatpak
- Also happens with development version: Yes
# Steps to reproduce <!-- Explain in detail how the issue can be reproduced. -->
1. Select a file
2. Press Delete
# Expected Behavior
No floating bar that says `“” selected` in the bottom right corner.
# Actual Behavior
The floating bar in the bottom right corner is shown and says `“” selected`.
# Additional Information
Photo of the issue![Screenshot_from_2024-03-08_11-15-03](/uploads/b3c0a01f6f88d78b57fca65e3f435ac2/Screenshot_from_2024-03-08_11-15-03.png)GNOME 46Khalid Abu ShawaribKhalid Abu Shawaribhttps://gitlab.gnome.org/GNOME/nautilus/-/issues/3353[46.0] Renaming a file logs system journal warning: Attempted to add non-exis...2024-03-25T23:09:26Ztekstryder[46.0] Renaming a file logs system journal warning: Attempted to add non-existent file "file URI" to the view.- Arch Linux | Kernel 6.7.9
- Gnome-shell | Mutter 46.rc
- Wayland (*meson_options: xwayland=false*)
- `Nautilus 46.rc`
### Bug summary
Per https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/1383#note_2037390, filing a bug report...- Arch Linux | Kernel 6.7.9
- Gnome-shell | Mutter 46.rc
- Wayland (*meson_options: xwayland=false*)
- `Nautilus 46.rc`
### Bug summary
Per https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/1383#note_2037390, filing a bug report for an individual, reproducible occurrence of this issue.
With the URI added to the debug message, it show the expected before / after filenames when the issue occurs.
```
(org.gnome.Nautilus:374400): nautilus-window-DEBUG: 14:59:09.808: Finished loading window for uri file:///mnt/Data/Temp
(org.gnome.Nautilus:374400): Tracker-DEBUG: 14:59:15.040: Freed 1 readonly interfaces
(org.gnome.Nautilus:374400): nautilus-view-DEBUG: 14:59:19.667: Selection changed in window 0x5d0d7073b640
(org.gnome.Nautilus:374400): nautilus-file-DEBUG: 14:59:19.667: file:///mnt/Data/Temp/panel-jiggle-bug
(org.gnome.Nautilus:374400): nautilus-previewer-DEBUG: 14:59:19.677: Unable to create NautilusPreviewer2 proxy: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable
(org.gnome.Nautilus:374400): nautilus-error-reporting-DEBUG: 14:59:32.717: Renaming file file:///mnt/Data/Temp/panel-jiggle-bug to panel-jiggle-bug-bug
(org.gnome.Nautilus:374400): nautilus-view-DEBUG: 14:59:32.719: Files added in window 0x5d0d7073b640: file:///mnt/Data/Temp
(org.gnome.Nautilus:374400): nautilus-file-DEBUG: 14:59:32.719: file:///mnt/Data/Temp/panel-jiggle-bug-bug
(org.gnome.Nautilus:374400): nautilus-async-jobs-DEBUG: 14:59:32.719: starting file info in 0x5d0d71c26850
(org.gnome.Nautilus:374400): nautilus-view-DEBUG: 14:59:32.719: Files changed in window (0x5d0d7073b640) file:///mnt/Data/Temp
(org.gnome.Nautilus:374400): nautilus-file-DEBUG: 14:59:32.719: file:///mnt/Data/Temp/panel-jiggle-bug-bug
(org.gnome.Nautilus:374400): nautilus-view-DEBUG: 14:59:32.719: Files changed in window (0x5d0d7073b640) file:///mnt/Data/Temp
(org.gnome.Nautilus:374400): nautilus-file-DEBUG: 14:59:32.719: file:///mnt/Data/Temp/panel-jiggle-bug-bug (gone)
(org.gnome.Nautilus:374400): nautilus-view-DEBUG: 14:59:32.719: Files changed in window (0x5d0d7073b640) file:///mnt/Data/Temp
(org.gnome.Nautilus:374400): nautilus-file-DEBUG: 14:59:32.719: file:///mnt/Data/Temp/panel-jiggle-bug-bug
(org.gnome.Nautilus:374400): nautilus-undo-DEBUG: 14:59:32.719: Setting undo information 0x5d0d71981000
(org.gnome.Nautilus:374400): nautilus-view-DEBUG: 14:59:32.720: Files changed in window (0x5d0d7073b640) file:///mnt/Data/Temp
(org.gnome.Nautilus:374400): nautilus-file-DEBUG: 14:59:32.720: file:///mnt/Data/Temp/panel-jiggle-bug-bug (gone)
(org.gnome.Nautilus:374400): nautilus-async-jobs-DEBUG: 14:59:32.720: stopping file info in 0x5d0d71c26850
(org.gnome.Nautilus:374400): nautilus-view-WARNING **: 14:59:32.819: Attempted to add non-existent file "file:///mnt/Data/Temp/panel-jiggle-bug-bug" to the view.
(org.gnome.Nautilus:374400): nautilus-file-DEBUG: 14:59:32.819: Called file_get_icon(), at size 16
(org.gnome.Nautilus:374400): nautilus-previewer-DEBUG: 14:59:32.820: Unable to create NautilusPreviewer2 proxy: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable
```
When renaming an example file `panel-jiggle-bug` to `panel-jiggle-bug-bug` using the Nautilus context menu, the file is renamed but the warning is logged in the system journal.
### Steps to reproduce:
1) Rename a file or folder in Nautilus.
It appears https://gitlab.gnome.org/GNOME/nautilus/-/issues/3200 is destined to be closed in favor of separate, specific issue reports.
For whatever reason, the newly-named file is debug logged as 'gone', seemingly before the rename action completes asynchronously.https://gitlab.gnome.org/GNOME/gnome-autoar/-/issues/47Nautilus can't decompress multipart zip file2024-03-05T09:13:33ZMerlijn SebrechtsNautilus can't decompress multipart zip file<!--
It's very helpful to know if the bug also happens in the latest development version.
It can be installed alongside the regular version with these instructions:
1. Make sure that Flatpak is installed (see https://flatpak.org/setup )...<!--
It's very helpful to know if the bug also happens in the latest development version.
It can be installed alongside the regular version with these instructions:
1. Make sure that Flatpak is installed (see https://flatpak.org/setup )
2. Copy and run the following command in the Terminal or Console app:
flatpak install --from https://nightly.gnome.org/repo/appstream/org.gnome.NautilusDevel.flatpakref
3. Launch the development version (normal Files logo with yellow and black stripes), e.g. with:
flatpak run org.gnome.NautilusDevel
-->
Nautilus can't extract a multipart zip file.
# Affected Version
- Version: Flatpak devel
- Distribution: Ubuntu & Flatpak
- Also happens with development version: Yes
# Steps to reproduce <!-- Explain in detail how the issue can be reproduced. -->
1. Download this testfile [testfile_multipart_zip_example_archive.zip](/uploads/c94047c4aa72c6addebe9bf16b383a2e/testfile_multipart_zip_example_archive.zip)
2. Extract it however you want. Inside of it are 4 files:
```
testfile_multipart_zip_example.z01
testfile_multipart_zip_example.z02
testfile_multipart_zip_example.z03
testfile_multipart_zip_example.zip
```
3. Try to extract `testfile_multipart_zip_example.zip` using Nautilus.
# Expected Behavior
The file gets unzipped
# Actual Behavior
"There was an error while extracting ... : not an archive"
# Additional Information
No log output when starting the flatpak from the cli.
If you don't trust my random zip and want to generate it yourself:
```shell
base64 /dev/urandom | head -c 5000000 > testfile.txt
zip -s 1 testfile_multipart_zip_example.zip testfile.txt
```https://gitlab.gnome.org/GNOME/nautilus/-/issues/3339Random crash when cutting/pasting file2024-03-05T08:57:08ZSébastien MaillardRandom crash when cutting/pasting file# Affected Version
- Version: 45.2
- Distribution: Ubuntu 23.10
- Also happens with development version: No
# Steps to reproduce
1. Open 2 tabs on 2 different folders
2. In the first tab, cut a file (Ctrl-X)
2. Navigate to the second ta...# Affected Version
- Version: 45.2
- Distribution: Ubuntu 23.10
- Also happens with development version: No
# Steps to reproduce
1. Open 2 tabs on 2 different folders
2. In the first tab, cut a file (Ctrl-X)
2. Navigate to the second tab
3. Paste the file (Ctrl-V)
# Expected Behavior
The file has been moved between the 2 folders and Files doesn't crash.
# Actual Behavior
On random occasions, Files either:
- freezes for a few seconds (the dialog to kill it or wait appears) and then crashes
- crashes instantly
Please note that despite Files' crash, the file has successfully been moved.
# Additional Information
- When starting Nautilus in debug mode, the following warning shows up right when Files crashes:
- `** (org.gnome.Nautilus:61400): WARNING **: 21:29:31.964: Attempted to add a non-existent file to the view.`
- Please note that when trying to reproduce the issue with the Flatpak development version, I sometimes get the above warning but Files doesn't crash
- Also note that once the warning has appeared in the development version, after attempting to reproduce the issue dozens of times, the warning never shows up anymore until I restart Nautilus
- This crash happens very frequently, sometimes after the first cut/paste, usually after a few ; I rarely can cut/paste more than a dozens times before a crash, which is pretty annoying since my workflow involves this operation a lot
- I can also reproduce the bug by moving the file between the 2 folders using the mouse
- I've never experienced this crash in the past, it started around 3 weeks ago after a software update
- Full stack trace: [coredumpctl_gdb.txt](/uploads/6a7f8e1e78ea299bbc61fa5722ac532c/coredumpctl_gdb.txt)https://gitlab.gnome.org/GNOME/gvfs/-/issues/718Cannot access an NFS share via server URL2024-03-11T20:36:53ZIgetinCannot access an NFS share via server URL# Affected Version
- Version: 45.2.1
- Distribution: Fedora 39
- Also happens with development version: Yes (46.rc)
# Steps to reproduce
1. Open Nautilus
2. Click "Other Locations" in the sidebar
3. Enter the URL of the NFS share to th...# Affected Version
- Version: 45.2.1
- Distribution: Fedora 39
- Also happens with development version: Yes (46.rc)
# Steps to reproduce
1. Open Nautilus
2. Click "Other Locations" in the sidebar
3. Enter the URL of the NFS share to the address field on the bottom
4. Click "Connect"
# Expected Behavior
Nautilus should connect to the NFS server and I should be able to access and view the files on the share.
# Actual Behavior
A dialog is shown with the error "Mount point does not exist".
![image](/uploads/0cc4680242d107876eafb3574d67f458/image.png){width=35%}
# Additional Information
I think the URL is right, and the tooltip in the "Other Locations" view shows that the prefix is supported:
![image](/uploads/ba992fd520df8ccd1faa86cb2efc2747/image.png){width=35%}
The server **should** also be configured correctly, since I can mount the share just fine with `mount`, e.g.:
```bash
sudo mount -t nfs 192.168.2.123:/ /media/nfs_share
```
The files are then browsable in Nautilus.
## Server
The NFS server is running on another Fedora 39 machine. It's running via the `nfs-server` systemd service that comes with the `nfs-utils` package (the currently installed version is 2.6.4).
Here's how the share is configured on the server:
`/etc/exports`:
```
/storage/merged 192.168.2.123/24(rw,sync,fsid=root)
```https://gitlab.gnome.org/GNOME/meld/-/issues/825Meld messes up file permissions on Windows2024-03-10T00:28:41ZpkzcMeld messes up file permissions on WindowsAfter having modified a file in Meld and saving it, the "Read & Execute" flag for the owner gets set on that file under Windows. I use cygwin git and the ACL flag is reflected in the file permissions which interacts badly with git.
Woul...After having modified a file in Meld and saving it, the "Read & Execute" flag for the owner gets set on that file under Windows. I use cygwin git and the ACL flag is reflected in the file permissions which interacts badly with git.
Would it be possible to make Meld preserve the ACL flags of the files it writes to?
I worked around this problem by running Meld from a wrapper script which restores the file permissions of the files under git control after Meld has terminated, but I regard it to be very awkward.https://gitlab.gnome.org/GNOME/gtk/-/issues/6465Corner case: clicking an event in the view with the left + right mouse button...2024-03-27T00:29:12ZJeff FortinCorner case: clicking an event in the view with the left + right mouse buttons simultaneously will deadlock the mouse input grab, preventing popover from showing and blocking the UI from being interacted with on WaylandThis is almost the same thing as issue gnome-calendar#1173, and also a pretty unlikely corner case, but I'm reporting it "just in case".
Running the git version on Wayland:
In the month view, week view or sidebar, click an event with b...This is almost the same thing as issue gnome-calendar#1173, and also a pretty unlikely corner case, but I'm reporting it "just in case".
Running the git version on Wayland:
In the month view, week view or sidebar, click an event with both mouse buttons at the same time (or one button after another in a very quick sequence).
As a result:
* No popover will be shown
* The UI will no longer respond to mouse clicks until you break the deadlock (see below); the only way to quit the application will be to kill the process externally.
* Tooltips on hover will still work
* Keyboard navigation will still work, although activating events with the `Enter` key will not work
**To break out of the deadlock**, you need to switch between the Week and Month views.
The easiest/fastest way for this is to just hit the `Alt+1` and `Alt+2` keyboard shortcuts.
Otherwise, the much more complicated way to do the same thing is to do this keyboard navigation keys sequence:
1. `Ctrl+F` to activate the searchbar
2. `Shift+Tab`
3. `Shift+Tab` again, or `Left arrow` key, to focus the "Week" view switcher button
4. `Spacebar` or `Enter` to switch to week view
5. `Tab` to focus the "Month" view switcher button
6. `Spacebar` or `Enter` to switch back to Month view
Once you are switched back to the view you were in, the Popover widget will suddenly appear on the event and you will be able to interact again with the UI using the mouse.
----
This is a low-priority issue because:
* While clicking with both buttons is unlikely, I'm only reporting it because of the potential UI lockup, which might be problematic in the event where users encounter this by accident.
* I don't know if it's a Calendar issue, or a GTK issue.https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1173Corner case: double-clicking an event in the view will cause critical GTK 'GD...2024-02-22T03:24:16ZJeff FortinCorner case: double-clicking an event in the view will cause critical GTK 'GDK_IS_SURFACE (surface)' failed assertions from popoverI don't know if this is Calendar's fault or GTK's, but... With the git/46 version, in the month view or week view, if you click an event twice in less than a second (i.e. a double-click), you will get these errors in GNOME Builder's cons...I don't know if this is Calendar's fault or GTK's, but... With the git/46 version, in the month view or week view, if you click an event twice in less than a second (i.e. a double-click), you will get these errors in GNOME Builder's console when GNOME Calendar tries to dismiss (or reopen?) the popover widget:
```
18:25:10.639963 GcalEventWidget: TRACE: EXIT: gcal_event_widget_show_preview():981
18:25:11.142947 Gdk: CRITICAL: gdk_surface_get_device_position: assertion 'GDK_IS_SURFACE (surface)' failed
18:25:11.143030 Gtk: CRITICAL: _gtk_widget_find_at_coords: assertion 'GDK_IS_SURFACE (surface)' failed
18:25:11.600936 GcalEventWidget: TRACE: ENTRY: gcal_event_widget_show_preview():964
```
This is a low-severity/low-priority bug:
* It is really an unlikely corner case scenario
* The app doesn't crash nor freeze, and seems to continue working normally, but it is just "probably better" to not have this occur.https://gitlab.gnome.org/GNOME/nautilus/-/issues/3327Nautilus crashed while I was viewing a folder2024-02-20T21:58:43ZAutomeris naranjaNautilus crashed while I was viewing a folder## Affected version
nautilus-45.2.1-1.fc39.x86_64
## Description
Nautilus crash when I was viewing a folder. I don't know how to reproduce this, so I can't test if this happens in Nightly builds.
## Backtrace
<details><summary>Click to...## Affected version
nautilus-45.2.1-1.fc39.x86_64
## Description
Nautilus crash when I was viewing a folder. I don't know how to reproduce this, so I can't test if this happens in Nightly builds.
## Backtrace
<details><summary>Click to expand</summary>
```
#0 0x00007f9200000000 in ?? ()
No symbol table info available.
#1 0x00007f9249cb5341 in g_bytes_unref (bytes=0x564ed919f0f0) at ../glib/gbytes.c:337
No locals.
#2 g_bytes_unref (bytes=0x564ed919f0f0) at ../glib/gbytes.c:329
No locals.
#3 0x00007f9249d241bb in g_variant_unref (value=0x564ed9069630) at ../glib/gvariant-core.c:803
__func__ = "g_variant_unref"
#4 0x00007f9249cca0d2 in g_hash_table_remove_all_nodes (hash_table=0x564ed88f6d70, notify=<optimized out>, destruction=<optimized out>) at ../glib/ghash.c:710
i = 0
key = <optimized out>
value = <optimized out>
old_size = <optimized out>
old_keys = 0x564ed8fcfee0
old_values = 0x564ed90695c0
old_hashes = 0x564ed88f6de0
old_have_big_keys = 1
old_have_big_values = 1
#5 0x00007f9249cce35b in g_hash_table_remove_all_nodes (destruction=1, notify=1, hash_table=0x564ed88f6d70) at ../glib/ghash.c:632
i = <optimized out>
key = <optimized out>
value = <optimized out>
old_size = <optimized out>
old_keys = <optimized out>
old_values = <optimized out>
old_hashes = <optimized out>
old_have_big_keys = <optimized out>
old_have_big_values = <optimized out>
#6 g_hash_table_unref (hash_table=0x564ed88f6d70) at ../glib/ghash.c:1492
__func__ = "g_hash_table_unref"
#7 0x00007f9249315285 in g_menu_clear_item (item=0x564ed907b9b0) at ../gio/gmenu.c:457
No locals.
#8 g_menu_finalize (object=0x564ed9002940) at ../gio/gmenu.c:526
menu = 0x564ed9002940
items = 0x564ed907b940
n_items = <optimized out>
i = <optimized out>
#9 0x00007f92490b5a93 in g_object_unref (_object=0x564ed9002940) at ../gobject/gobject.c:3941
weak_locations = <optimized out>
nqueue = 0x564ed8901c80
object = <optimized out>
old_ref = <optimized out>
retry_atomic_decrement1 = <optimized out>
object = <optimized out>
old_ref = <optimized out>
__func__ = <optimized out>
retry_atomic_decrement1 = <optimized out>
_g_boolean_var_133 = <optimized out>
gaig_temp = <optimized out>
weak_locations = <optimized out>
nqueue = <optimized out>
gaig_temp = <optimized out>
_pp = <optimized out>
_ptr = <optimized out>
gaig_temp = <optimized out>
gaig_temp = <optimized out>
_g_boolean_var_144 = <optimized out>
_g_boolean_var_145 = <optimized out>
#10 g_object_unref (_object=0x564ed9002940) at ../gobject/gobject.c:3805
object = 0x564ed9002940
old_ref = <optimized out>
retry_atomic_decrement1 = <optimized out>
__func__ = "g_object_unref"
gaig_temp = <optimized out>
weak_locations = <optimized out>
nqueue = <optimized out>
gaig_temp = <optimized out>
_pp = <optimized out>
_ptr = <optimized out>
gaig_temp = <optimized out>
gaig_temp = <optimized out>
_g_boolean_var_144 = <optimized out>
_g_boolean_var_145 = <optimized out>
#11 0x00007f9249cca0d2 in g_hash_table_remove_all_nodes (hash_table=0x564ed905a220, notify=<optimized out>, destruction=<optimized out>) at ../glib/ghash.c:710
i = 3
key = <optimized out>
value = <optimized out>
old_size = <optimized out>
old_keys = 0x564ed9001fa0
old_values = 0x564ed9040760
old_hashes = 0x564ed9001f40
old_have_big_keys = 1
old_have_big_values = 1
#12 0x00007f9249cce35b in g_hash_table_remove_all_nodes (destruction=1, notify=1, hash_table=0x564ed905a220) at ../glib/ghash.c:632
i = <optimized out>
key = <optimized out>
value = <optimized out>
old_size = <optimized out>
old_keys = <optimized out>
old_values = <optimized out>
old_hashes = <optimized out>
old_have_big_keys = <optimized out>
old_have_big_values = <optimized out>
#13 g_hash_table_unref (hash_table=0x564ed905a220) at ../glib/ghash.c:1492
__func__ = "g_hash_table_unref"
#14 0x00007f9249315293 in g_menu_clear_item (item=0x564ed8eae180) at ../gio/gmenu.c:459
No locals.
#15 g_menu_finalize (object=0x564ed91a5fd0) at ../gio/gmenu.c:526
menu = 0x564ed91a5fd0
items = 0x564ed8eae140
n_items = <optimized out>
i = <optimized out>
#16 0x00007f92490b5a93 in g_object_unref (_object=0x564ed91a5fd0) at ../gobject/gobject.c:3941
weak_locations = <optimized out>
nqueue = 0x564ed8907530
object = <optimized out>
old_ref = <optimized out>
retry_atomic_decrement1 = <optimized out>
object = <optimized out>
old_ref = <optimized out>
__func__ = <optimized out>
retry_atomic_decrement1 = <optimized out>
_g_boolean_var_133 = <optimized out>
gaig_temp = <optimized out>
weak_locations = <optimized out>
nqueue = <optimized out>
gaig_temp = <optimized out>
_pp = <optimized out>
_ptr = <optimized out>
gaig_temp = <optimized out>
gaig_temp = <optimized out>
_g_boolean_var_144 = <optimized out>
_g_boolean_var_145 = <optimized out>
#17 g_object_unref (_object=0x564ed91a5fd0) at ../gobject/gobject.c:3805
object = 0x564ed91a5fd0
old_ref = <optimized out>
retry_atomic_decrement1 = <optimized out>
__func__ = "g_object_unref"
gaig_temp = <optimized out>
weak_locations = <optimized out>
nqueue = <optimized out>
gaig_temp = <optimized out>
_pp = <optimized out>
_ptr = <optimized out>
gaig_temp = <optimized out>
gaig_temp = <optimized out>
_g_boolean_var_144 = <optimized out>
_g_boolean_var_145 = <optimized out>
#18 0x0000564ed4095dad in real_update_context_menus (view=0x564ed8f36ae0) at ../src/nautilus-files-view.c:8443
_pp = 0x564ed8f368d8
_ptr = <optimized out>
priv = 0x564ed8f367a0
builder = 0x564ed9230e50
object = <optimized out>
#19 0x0000564ed408d14e in update_context_menus_timeout_callback (data=data@entry=0x564ed8f36ae0) at ../src/nautilus-files-view.c:4627
view = 0x564ed8f36ae0
priv = 0x564ed8f367a0
#20 0x00007f9249ce0799 in g_timeout_dispatch (source=0x564ed9066fd0, callback=0x564ed408d120 <update_context_menus_timeout_callback>, user_data=0x564ed8f36ae0) at ../glib/gmain.c:5121
timeout_source = 0x564ed9066fd0
again = <optimized out>
#21 0x00007f9249cdfe5c in g_main_dispatch (context=0x564ed5e1a340) at ../glib/gmain.c:3476
dispatch = 0x7f9249ce0770 <g_timeout_dispatch>
prev_source = 0x0
begin_time_nsec = 1221602711256
was_in_call = 0
user_data = 0x564ed8f36ae0
callback = 0x564ed408d120 <update_context_menus_timeout_callback>
cb_funcs = 0x7f9249dcc380 <g_source_callback_funcs>
cb_data = 0x564ed8fd7960
need_destroy = <optimized out>
source = 0x564ed9066fd0
current = 0x564ed5e23d60
i = 0
__func__ = <optimized out>
#22 g_main_context_dispatch_unlocked (context=0x564ed5e1a340) at ../glib/gmain.c:4284
No locals.
#23 0x00007f9249d3af18 in g_main_context_iterate_unlocked.isra.0 (context=context@entry=0x564ed5e1a340, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4349
max_priority = 2147483647
timeout = 4
some_ready = 1
nfds = 2
allocated_nfds = <optimized out>
fds = 0x564ed5e7e570
begin_time_nsec = 1221598438506
#24 0x00007f9249cddad3 in g_main_context_iteration (context=context@entry=0x564ed5e1a340, may_block=may_block@entry=1) at ../glib/gmain.c:4414
retval = <optimized out>
#25 0x00007f924931292d in g_application_run (application=application@entry=0x564ed5e04e00, argc=argc@entry=2, argv=argv@entry=0x7fffaaf69c58) at ../gio/gapplication.c:2577
arguments = 0x564ed5e7e570
status = 0
context = 0x564ed5e1a340
acquired_context = <optimized out>
__func__ = "g_application_run"
#26 0x0000564ed402258e in main (argc=2, argv=0x7fffaaf69c58) at ../src/nautilus-main.c:81
retval = <optimized out>
application = 0x564ed5e04e00
```
</details>https://gitlab.gnome.org/GNOME/nautilus/-/issues/3324Onscreen keyboard does not work with folder creation/editing.2024-02-22T17:58:13ZJustin CampoOnscreen keyboard does not work with folder creation/editing.# Affected Version
- Version: 43.2
- Distribution: Debian 12.5
- Also happens with development version: I can't install
# Steps to reproduce
1. Create new folder by right clicking
2. Right click rename folder, hit backspace to delete la...# Affected Version
- Version: 43.2
- Distribution: Debian 12.5
- Also happens with development version: I can't install
# Steps to reproduce
1. Create new folder by right clicking
2. Right click rename folder, hit backspace to delete last character of folder name
# Expected Behavior
1. You can enter the name of the folder with the onscreen keyboard
2. You will delete the last character of the folder name
# Actual Behavior
1. Onscreen keyboard does not display/there is no way to enter folder name without prompt disappearing
2. Onscreen keyboard closes and there is no way to edit existing folder namehttps://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1164New event popover closes when hitting "Enter" after typing special characters...2024-02-19T07:18:27ZlightonfluxNew event popover closes when hitting "Enter" after typing special characters with "typing booster"### Affected version
46 alpha
### Bug summary
New event pop over closes when entering "special" characters with certain input methods like typing booster.
This might also affect other input methods.
### Steps to reproduce
1. Add t...### Affected version
46 alpha
### Bug summary
New event pop over closes when entering "special" characters with certain input methods like typing booster.
This might also affect other input methods.
### Steps to reproduce
1. Add typing booster an input method to your keyboard configuration.
2. Switch to it (super + space)
3. Open calendar, click to add a new event
4. Select text input of the popover
5. Enter something like "penguin" and confirm with "enter" key while typing booster selection is highlighted
6. Observe that the pop over disappears
### What happened
The pop over closes.
### What did you expect to happen
The popover should stay open.
### Relevant logs, screenshots, screencasts etc.
[Bildschirmaufzeichnung vom 2024-02-17, 21-49-44.webm](/uploads/1255d1bc667664ed59baa7785f278dc1/Bildschirmaufzeichnung_vom_2024-02-17__21-49-44.webm)