[Desktop-packages] [Bug 1971168] Re: [snap] Files on local network shares are not opened / written
** Description changed: [ Impact ] When the user is running a containerized application (like the snapped Firefox or Chromium), and tries to save a document, the xdg-desktop- portal-gnome backend does show remote drives (like SMB or SFTP ones), and allows to choose them, but then the save operation fails. The previous backend, xdg-desktop-portal-gtk, did work fine in these cases because it returned the local path that corresponded to the remote file when exported by Gvfs using FUSE, so this behaviour is not only a serious bug, but also a regression. - The old behavior has been now "set on stone" in the XDG portal + The old behavior has now been "set on stone" in the XDG portal specification, mandating that the backends must always return local paths, no matter if the chosen file is a local or remote one, by using FUSE. [ Test plan] Steps to reproduce: 1. Run Firefox as a Snap package in Ubuntu 22.04 2. Have a SMB file server available where the network shares can be mounted just by clicking on the share in Nautilus file manager (smb:// protocol, usually mounted dynamically via `/var/run/user/.../gvfs/...`) 3. Have one such share mounted and writable 4. Open any website containing images in Firefox 5. Right-click on an image and select "Save Image As..." 6. In the file save dialog, navigate to the mounted share 7. Assert content of network share is visible and browsable from within the save dialog 8. Select "Save" at any folder in the network share Actual behavior: * File is not saved to selected network share location * No download entry is created * No error is shown Expected behavior: * File is saved to selected network share location * No error is shown [ Where problems could occur ] - If the remote drives aren't exported as local files by Gvfs using FUSE, the patch won't work and the behaviour will be the same than now. - Any hidden bug in g_file_get_path() when managing remote drives could be triggered by this patch. [ Additional information ] * When saving to a folder on the local machine instead, saving works correctly as expected * In contrast to files, new folders that are created from within the save dialog are saved correctly on the network share * Similar situation when trying to open a file with Ctrl + O on a network share from Firefox / Chromium. After double-clicking e.g. an image file in the file dialog, the file dialog closes but nothing happens otherwise. Opening an image on a local folder works fine. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xdg-desktop-portal in Ubuntu. https://bugs.launchpad.net/bugs/1971168 Title: [snap] Files on local network shares are not opened / written Status in Mozilla Firefox: Fix Released Status in firefox package in Ubuntu: Triaged Status in xdg-desktop-portal package in Ubuntu: Triaged Status in xdg-desktop-portal-gnome package in Ubuntu: Fix Released Status in xdg-desktop-portal-gnome source package in Jammy: Fix Committed Status in xdg-desktop-portal-gnome source package in Lunar: Won't Fix Bug description: [ Impact ] When the user is running a containerized application (like the snapped Firefox or Chromium), and tries to save a document, the xdg-desktop- portal-gnome backend does show remote drives (like SMB or SFTP ones), and allows to choose them, but then the save operation fails. The previous backend, xdg-desktop-portal-gtk, did work fine in these cases because it returned the local path that corresponded to the remote file when exported by Gvfs using FUSE, so this behaviour is not only a serious bug, but also a regression. The old behavior has now been "set on stone" in the XDG portal specification, mandating that the backends must always return local paths, no matter if the chosen file is a local or remote one, by using FUSE. [ Test plan] Steps to reproduce: 1. Run Firefox as a Snap package in Ubuntu 22.04 2. Have a SMB file server available where the network shares can be mounted just by clicking on the share in Nautilus file manager (smb:// protocol, usually mounted dynamically via `/var/run/user/.../gvfs/...`) 3. Have one such share mounted and writable 4. Open any website containing images in Firefox 5. Right-click on an image and select "Save Image As..." 6. In the file save dialog, navigate to the mounted share 7. Assert content of network share is visible and browsable from within the save dialog 8. Select "Save" at any folder in the network share Actual behavior: * File is not saved to selected network share location * No download entry is created * No error is shown Expected behavior: * File is saved to selected network share location * No error is shown [ Where problems could occur ] - If the remote drives aren't exported as local files by Gvfs using
[Desktop-packages] [Bug 1971168] Re: [snap] Files on local network shares are not opened / written
** Description changed: [ Impact ] When the user is running a containerized application (like the snapped Firefox or Chromium), and tries to save a document, the xdg-desktop- portal-gnome backend does show remote drives (like SMB or SFTP ones), and allows to choose them, but then the save operation fails. The previous backend, xdg-desktop-portal-gtk, did work fine in these - cases, because it returned the local path that corresponded to the local - file exported by Gvfs using FUSE, so this behaviour is not only a + cases because it returned the local path that corresponded to the remote + file when exported by Gvfs using FUSE, so this behaviour is not only a serious bug, but also a regression. + + The old behavior has been now "set on stone" in the XDG portal + specification, mandating that the backends must always return local + paths, no matter if the chosen file is a local or remote one, by using + FUSE. [ Test plan] Steps to reproduce: 1. Run Firefox as a Snap package in Ubuntu 22.04 2. Have a SMB file server available where the network shares can be mounted just by clicking on the share in Nautilus file manager (smb:// protocol, usually mounted dynamically via `/var/run/user/.../gvfs/...`) 3. Have one such share mounted and writable 4. Open any website containing images in Firefox 5. Right-click on an image and select "Save Image As..." 6. In the file save dialog, navigate to the mounted share 7. Assert content of network share is visible and browsable from within the save dialog 8. Select "Save" at any folder in the network share Actual behavior: * File is not saved to selected network share location * No download entry is created * No error is shown Expected behavior: * File is saved to selected network share location * No error is shown [ Where problems could occur ] - If the remote drives aren't exported as local files by Gvfs using FUSE, the patch won't work and the behaviour will be the same than now. - Any hidden bug in g_file_get_path() when managing remote drives could be triggered by this patch. [ Additional information ] * When saving to a folder on the local machine instead, saving works correctly as expected * In contrast to files, new folders that are created from within the save dialog are saved correctly on the network share * Similar situation when trying to open a file with Ctrl + O on a network share from Firefox / Chromium. After double-clicking e.g. an image file in the file dialog, the file dialog closes but nothing happens otherwise. Opening an image on a local folder works fine. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xdg-desktop-portal in Ubuntu. https://bugs.launchpad.net/bugs/1971168 Title: [snap] Files on local network shares are not opened / written Status in Mozilla Firefox: Fix Released Status in firefox package in Ubuntu: Triaged Status in xdg-desktop-portal package in Ubuntu: Triaged Status in xdg-desktop-portal-gnome package in Ubuntu: Fix Released Status in xdg-desktop-portal-gnome source package in Jammy: Fix Committed Status in xdg-desktop-portal-gnome source package in Lunar: Won't Fix Bug description: [ Impact ] When the user is running a containerized application (like the snapped Firefox or Chromium), and tries to save a document, the xdg-desktop- portal-gnome backend does show remote drives (like SMB or SFTP ones), and allows to choose them, but then the save operation fails. The previous backend, xdg-desktop-portal-gtk, did work fine in these cases because it returned the local path that corresponded to the remote file when exported by Gvfs using FUSE, so this behaviour is not only a serious bug, but also a regression. The old behavior has been now "set on stone" in the XDG portal specification, mandating that the backends must always return local paths, no matter if the chosen file is a local or remote one, by using FUSE. [ Test plan] Steps to reproduce: 1. Run Firefox as a Snap package in Ubuntu 22.04 2. Have a SMB file server available where the network shares can be mounted just by clicking on the share in Nautilus file manager (smb:// protocol, usually mounted dynamically via `/var/run/user/.../gvfs/...`) 3. Have one such share mounted and writable 4. Open any website containing images in Firefox 5. Right-click on an image and select "Save Image As..." 6. In the file save dialog, navigate to the mounted share 7. Assert content of network share is visible and browsable from within the save dialog 8. Select "Save" at any folder in the network share Actual behavior: * File is not saved to selected network share location * No download entry is created * No error is shown Expected behavior: * File is saved to selected network share location * No error is shown [ Where problems could
[Desktop-packages] [Bug 1971168] Re: [snap] Files on local network shares are not opened / written
** Changed in: xdg-desktop-portal-gnome (Ubuntu Jammy) Status: Triaged => Fix Committed ** Changed in: xdg-desktop-portal-gnome (Ubuntu Jammy) Assignee: (unassigned) => Sergio Costas (rastersoft-gmail) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xdg-desktop-portal in Ubuntu. https://bugs.launchpad.net/bugs/1971168 Title: [snap] Files on local network shares are not opened / written Status in Mozilla Firefox: Fix Released Status in firefox package in Ubuntu: Triaged Status in xdg-desktop-portal package in Ubuntu: Triaged Status in xdg-desktop-portal-gnome package in Ubuntu: Fix Released Status in xdg-desktop-portal-gnome source package in Jammy: Fix Committed Status in xdg-desktop-portal-gnome source package in Lunar: Won't Fix Bug description: [ Impact ] When the user is running a containerized application (like the snapped Firefox or Chromium), and tries to save a document, the xdg-desktop- portal-gnome backend does show remote drives (like SMB or SFTP ones), and allows to choose them, but then the save operation fails. The previous backend, xdg-desktop-portal-gtk, did work fine in these cases, because it returned the local path that corresponded to the local file exported by Gvfs using FUSE, so this behaviour is not only a serious bug, but also a regression. [ Test plan] Steps to reproduce: 1. Run Firefox as a Snap package in Ubuntu 22.04 2. Have a SMB file server available where the network shares can be mounted just by clicking on the share in Nautilus file manager (smb:// protocol, usually mounted dynamically via `/var/run/user/.../gvfs/...`) 3. Have one such share mounted and writable 4. Open any website containing images in Firefox 5. Right-click on an image and select "Save Image As..." 6. In the file save dialog, navigate to the mounted share 7. Assert content of network share is visible and browsable from within the save dialog 8. Select "Save" at any folder in the network share Actual behavior: * File is not saved to selected network share location * No download entry is created * No error is shown Expected behavior: * File is saved to selected network share location * No error is shown [ Where problems could occur ] - If the remote drives aren't exported as local files by Gvfs using FUSE, the patch won't work and the behaviour will be the same than now. - Any hidden bug in g_file_get_path() when managing remote drives could be triggered by this patch. [ Additional information ] * When saving to a folder on the local machine instead, saving works correctly as expected * In contrast to files, new folders that are created from within the save dialog are saved correctly on the network share * Similar situation when trying to open a file with Ctrl + O on a network share from Firefox / Chromium. After double-clicking e.g. an image file in the file dialog, the file dialog closes but nothing happens otherwise. Opening an image on a local folder works fine. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1971168/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1971168] Re: [snap] Files on local network shares are not opened / written
The patch is still queued https://salsa.debian.org/gnome-team/xdg- desktop-portal-gnome/-/merge_requests/10 I'll ping again. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xdg-desktop-portal in Ubuntu. https://bugs.launchpad.net/bugs/1971168 Title: [snap] Files on local network shares are not opened / written Status in Mozilla Firefox: Fix Released Status in firefox package in Ubuntu: Triaged Status in xdg-desktop-portal package in Ubuntu: Triaged Status in xdg-desktop-portal-gnome package in Ubuntu: Fix Released Status in xdg-desktop-portal-gnome source package in Jammy: Triaged Status in xdg-desktop-portal-gnome source package in Lunar: Won't Fix Bug description: [ Impact ] When the user is running a containerized application (like the snapped Firefox or Chromium), and tries to save a document, the xdg-desktop- portal-gnome backend does show remote drives (like SMB or SFTP ones), and allows to choose them, but then the save operation fails. The previous backend, xdg-desktop-portal-gtk, did work fine in these cases, because it returned the local path that corresponded to the local file exported by Gvfs using FUSE, so this behaviour is not only a serious bug, but also a regression. [ Test plan] Steps to reproduce: 1. Run Firefox as a Snap package in Ubuntu 22.04 2. Have a SMB file server available where the network shares can be mounted just by clicking on the share in Nautilus file manager (smb:// protocol, usually mounted dynamically via `/var/run/user/.../gvfs/...`) 3. Have one such share mounted and writable 4. Open any website containing images in Firefox 5. Right-click on an image and select "Save Image As..." 6. In the file save dialog, navigate to the mounted share 7. Assert content of network share is visible and browsable from within the save dialog 8. Select "Save" at any folder in the network share Actual behavior: * File is not saved to selected network share location * No download entry is created * No error is shown Expected behavior: * File is saved to selected network share location * No error is shown [ Where problems could occur ] - If the remote drives aren't exported as local files by Gvfs using FUSE, the patch won't work and the behaviour will be the same than now. - Any hidden bug in g_file_get_path() when managing remote drives could be triggered by this patch. [ Additional information ] * When saving to a folder on the local machine instead, saving works correctly as expected * In contrast to files, new folders that are created from within the save dialog are saved correctly on the network share * Similar situation when trying to open a file with Ctrl + O on a network share from Firefox / Chromium. After double-clicking e.g. an image file in the file dialog, the file dialog closes but nothing happens otherwise. Opening an image on a local folder works fine. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1971168/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2016013] Re: New windows don't get centered if Desktop Icons NG is loaded
Sorry for the delay. Yes, it is because of that. In Gnome 46 is a new API that allows to mark a window as "desktop window" and should fix it, and I want to use it, but I'm waiting for 24.04 to go out because it would be a big change, and I don't want to risk a LTS. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to mutter in Ubuntu. https://bugs.launchpad.net/bugs/2016013 Title: New windows don't get centered if Desktop Icons NG is loaded Status in gnome-shell-extension-desktop-icons-ng package in Ubuntu: Triaged Status in mutter package in Ubuntu: Triaged Bug description: New windows don't get centered if Desktop Icons NG is loaded. With vanilla GNOME, if an app window is too large for tiling (larger than a quarter of the screen) then it will be centered by default. But this doesn't happen when DING is loaded, probably because DING is incorrectly treated as an app window. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell-extension-desktop-icons-ng/+bug/2016013/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2051504] Re: 0.4.17-1ubuntu1 removes all output and input sinks in gnome settings
Added pipewire to the affected packages because the patch is for it. ** Also affects: pipewire (Ubuntu) Importance: Undecided Status: New ** Changed in: pipewire (Ubuntu) Assignee: (unassigned) => Sergio Costas (rastersoft-gmail) ** Changed in: pipewire (Ubuntu) Status: New => Confirmed ** Changed in: pipewire (Ubuntu) Importance: Undecided => High -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to pipewire in Ubuntu. https://bugs.launchpad.net/bugs/2051504 Title: 0.4.17-1ubuntu1 removes all output and input sinks in gnome settings Status in pipewire package in Ubuntu: Confirmed Status in wireplumber package in Ubuntu: Confirmed Bug description: After the changes committed as part of https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/1995707 (wireplumber 0.4.17-1ubuntu1), all input and output sinks are removed from gnome settings on reboot. Playing audio through celluloid (mpv) still works with the default sink, while Firefox Nightly refuses to play anything. I've tested this on two machines now; - One running on nvidia+X11, without snapd installed. - Another running on intel+wayland, also without snapd. Reverting to 0.4.17-1 works fine, and gnome settings lists all output and input sinks again. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/2051504/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1971168]
For 23.10, as soon as version 45.1 enters, it will be fixed. For 22.04 I prepared a SRU, but since it's a LTS version, it's a slow process. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xdg-desktop-portal in Ubuntu. https://bugs.launchpad.net/bugs/1971168 Title: [snap] Files on local network shares are not opened / written Status in Mozilla Firefox: Fix Released Status in firefox package in Ubuntu: Triaged Status in xdg-desktop-portal package in Ubuntu: Triaged Status in xdg-desktop-portal-gnome package in Ubuntu: Fix Released Status in xdg-desktop-portal-gnome source package in Jammy: Triaged Status in xdg-desktop-portal-gnome source package in Lunar: Triaged Bug description: [ Impact ] When the user is running a containerized application (like the snapped Firefox or Chromium), and tries to save a document, the xdg-desktop- portal-gnome backend does show remote drives (like SMB or SFTP ones), and allows to choose them, but then the save operation fails. The previous backend, xdg-desktop-portal-gtk, did work fine in these cases, because it returned the local path that corresponded to the local file exported by Gvfs using FUSE, so this behaviour is not only a serious bug, but also a regression. [ Test plan] Steps to reproduce: 1. Run Firefox as a Snap package in Ubuntu 22.04 2. Have a SMB file server available where the network shares can be mounted just by clicking on the share in Nautilus file manager (smb:// protocol, usually mounted dynamically via `/var/run/user/.../gvfs/...`) 3. Have one such share mounted and writable 4. Open any website containing images in Firefox 5. Right-click on an image and select "Save Image As..." 6. In the file save dialog, navigate to the mounted share 7. Assert content of network share is visible and browsable from within the save dialog 8. Select "Save" at any folder in the network share Actual behavior: * File is not saved to selected network share location * No download entry is created * No error is shown Expected behavior: * File is saved to selected network share location * No error is shown [ Where problems could occur ] - If the remote drives aren't exported as local files by Gvfs using FUSE, the patch won't work and the behaviour will be the same than now. - Any hidden bug in g_file_get_path() when managing remote drives could be triggered by this patch. [ Additional information ] * When saving to a folder on the local machine instead, saving works correctly as expected * In contrast to files, new folders that are created from within the save dialog are saved correctly on the network share * Similar situation when trying to open a file with Ctrl + O on a network share from Firefox / Chromium. After double-clicking e.g. an image file in the file dialog, the file dialog closes but nothing happens otherwise. Opening an image on a local folder works fine. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1971168/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1971168]
Yes, this can be considered as fixed. It was merged in upstream (gnome 46), and also backported to Gnome 45. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xdg-desktop-portal in Ubuntu. https://bugs.launchpad.net/bugs/1971168 Title: [snap] Files on local network shares are not opened / written Status in Mozilla Firefox: Fix Released Status in firefox package in Ubuntu: Triaged Status in xdg-desktop-portal package in Ubuntu: Triaged Status in xdg-desktop-portal-gnome package in Ubuntu: Fix Released Status in xdg-desktop-portal-gnome source package in Jammy: Triaged Status in xdg-desktop-portal-gnome source package in Lunar: Triaged Bug description: [ Impact ] When the user is running a containerized application (like the snapped Firefox or Chromium), and tries to save a document, the xdg-desktop- portal-gnome backend does show remote drives (like SMB or SFTP ones), and allows to choose them, but then the save operation fails. The previous backend, xdg-desktop-portal-gtk, did work fine in these cases, because it returned the local path that corresponded to the local file exported by Gvfs using FUSE, so this behaviour is not only a serious bug, but also a regression. [ Test plan] Steps to reproduce: 1. Run Firefox as a Snap package in Ubuntu 22.04 2. Have a SMB file server available where the network shares can be mounted just by clicking on the share in Nautilus file manager (smb:// protocol, usually mounted dynamically via `/var/run/user/.../gvfs/...`) 3. Have one such share mounted and writable 4. Open any website containing images in Firefox 5. Right-click on an image and select "Save Image As..." 6. In the file save dialog, navigate to the mounted share 7. Assert content of network share is visible and browsable from within the save dialog 8. Select "Save" at any folder in the network share Actual behavior: * File is not saved to selected network share location * No download entry is created * No error is shown Expected behavior: * File is saved to selected network share location * No error is shown [ Where problems could occur ] - If the remote drives aren't exported as local files by Gvfs using FUSE, the patch won't work and the behaviour will be the same than now. - Any hidden bug in g_file_get_path() when managing remote drives could be triggered by this patch. [ Additional information ] * When saving to a folder on the local machine instead, saving works correctly as expected * In contrast to files, new folders that are created from within the save dialog are saved correctly on the network share * Similar situation when trying to open a file with Ctrl + O on a network share from Firefox / Chromium. After double-clicking e.g. an image file in the file dialog, the file dialog closes but nothing happens otherwise. Opening an image on a local folder works fine. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1971168/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2037604] Re: Backport packages for 22.04.4 HWE stack
Can somebody modify the description to specify exactly how to do those tests, please? (which commands/parameters, and expected results). -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/2037604 Title: Backport packages for 22.04.4 HWE stack Status in directx-headers package in Ubuntu: Invalid Status in mesa package in Ubuntu: Invalid Status in rust-bindgen package in Ubuntu: Invalid Status in rust-clang-sys package in Ubuntu: Invalid Status in directx-headers source package in Jammy: Fix Committed Status in mesa source package in Jammy: Fix Committed Status in rust-bindgen source package in Jammy: Invalid Status in rust-clang-sys source package in Jammy: Invalid Bug description: [Impact] The graphics HWE stack from mantic needs to be backported for 22.04.4 directx-headers - build-dep of the new Mesa mesa - new major release (23.2.x) - new HW support, Meteor Lake.. [Test case] We want to cover at least 2-3 different, widely used and already previously supported GPU generations from both AMD and Intel which are supported by this release, as those are the ones that cover most bases; nouveau users tend to switch to the NVIDIA blob after installation. No need to test ancient GPU's supported by mesa-amber. And best to focus on the newer generations (~5y and newer) as the older ones are less likely to break at this point. - AMD: Vega, Navi1x (RX5000*), Navi2x (RX6000*), Navi3x (RX7000*) - Intel: gen9 (SKL/APL/KBL/CFL/WHL/CML), gen11 (ICL), gen12 (TGL/RKL/RPL/DG2) Install the new packages and run some tests: - check that the desktop is still using hw acceleration and hasn't fallen back to swrast/llvmpipe - run freely available benchmarks that torture the GPU (Unigine Heaven/Valley/Superposition) - run some games from Steam if possible and in each case check that there is no gfx corruption happening or worse. Note that upstream releases have already been tested for OpenGL and Vulkan conformance by their CI. [Where things could go wrong] This is a major update of Mesa, there could be regressions but we'll try to catch any with testing. And since it shares bugs with mantic, we'd already know if there are serious issues. We will backport the final 23.2.x at a later stage, the first backport is needed for enabling Intel Meteor Lake. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/directx-headers/+bug/2037604/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1971168] Re: [snap] Files on local network shares are not opened / written
Ok, I think that the problem is that the bug report is in "firefox" instead of "xdg-desktop-portal-gnome". I'll prepare a new bug report there with the patch from Bas van den Heuvel. Sorry for the mistake. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xdg-desktop-portal in Ubuntu. https://bugs.launchpad.net/bugs/1971168 Title: [snap] Files on local network shares are not opened / written Status in Mozilla Firefox: Confirmed Status in firefox package in Ubuntu: Triaged Status in xdg-desktop-portal package in Ubuntu: Triaged Status in xdg-desktop-portal-gnome package in Ubuntu: Fix Released Status in xdg-desktop-portal-gnome source package in Jammy: Triaged Status in xdg-desktop-portal-gnome source package in Lunar: Triaged Bug description: [ Impact ] When the user is running a containerized application (like the snapped Firefox or Chromium), and tries to save a document, the xdg-desktop- portal-gnome backend does show remote drives (like SMB or SFTP ones), and allows to choose them, but then the save operation fails. The previous backend, xdg-desktop-portal-gtk, did work fine in these cases, because it returned the local path that corresponded to the local file exported by Gvfs using FUSE, so this behaviour is not only a serious bug, but also a regression. [ Test plan] Steps to reproduce: 1. Run Firefox as a Snap package in Ubuntu 22.04 2. Have a SMB file server available where the network shares can be mounted just by clicking on the share in Nautilus file manager (smb:// protocol, usually mounted dynamically via `/var/run/user/.../gvfs/...`) 3. Have one such share mounted and writable 4. Open any website containing images in Firefox 5. Right-click on an image and select "Save Image As..." 6. In the file save dialog, navigate to the mounted share 7. Assert content of network share is visible and browsable from within the save dialog 8. Select "Save" at any folder in the network share Actual behavior: * File is not saved to selected network share location * No download entry is created * No error is shown Expected behavior: * File is saved to selected network share location * No error is shown [ Where problems could occur ] - If the remote drives aren't exported as local files by Gvfs using FUSE, the patch won't work and the behaviour will be the same than now. - Any hidden bug in g_file_get_path() when managing remote drives could be triggered by this patch. [ Additional information ] * When saving to a folder on the local machine instead, saving works correctly as expected * In contrast to files, new folders that are created from within the save dialog are saved correctly on the network share * Similar situation when trying to open a file with Ctrl + O on a network share from Firefox / Chromium. After double-clicking e.g. an image file in the file dialog, the file dialog closes but nothing happens otherwise. Opening an image on a local folder works fine. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1971168/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2048390] [NEW] Desktop icons doesn't support accessibility (specifically Orca)
Public bug reported: [ Impact ] Currently, the Desktop Icons NG (DING) extension included in Ubuntu doesn't support integration with screen readers like Orca. This is a disadvantage for visually impaired users. Since DING is implemented as a classic GTK application, it should be easy to wire it up to make use of the accessibility functions already available thanks to the ATK library. A patch for that has been recently uploaded to upstream, after a fix for this was requested by an user. The patch takes advantage of the already implemented keyboard navigation, and just makes these little changes: * sets a readable accessible description for the Desktop Icons window (because the application uses the invisible title bar to communicate with the extension, thus it contains just "odd characters and numbers") * sets an accessible description for each icon with the type and the visible name of the file, and marks each icon as focusable * when an icon is marked as selected, it gives the focus to it, thus triggering the screen reader to read the accessible description Also, the code for keyboard navigation is moved from the "key-press" event to the "key-release" event, because that's the event used by the accessibility subsystem, and not doing this results in an incorrect icon being read by it. [ Test plan ] * Enable the Orca screen reader by pressing Mod+Alt+S. A voice will say "Screen reader enabled" (or a similar, translated message). * Click on the desktop to give the focus to it. * Press the arrow keys to navigate with the keyboard through the icons. Only one icon should be highlighted, and it should change when the arrows are moved. * After the test, the screen reader can be disabled by pressing the same keys combination. Expected results: The screen reader should say the type and name of the selected icon, every time the arrow keys are pressed to change the selected icon. Current results: The screen reader remains silent while navigating with the keyboard. [ Where problems could occur ] A change in the way GTK manages the focus could result in the keyboard navigation to work incorrectly. ** Affects: gnome-shell-extension-desktop-icons-ng (Ubuntu) Importance: Undecided Status: New ** Patch added: "Patch to add accessibility support" https://bugs.launchpad.net/bugs/2048390/+attachment/5736866/+files/add-accessibility-support.diff -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-desktop-icons-ng in Ubuntu. https://bugs.launchpad.net/bugs/2048390 Title: Desktop icons doesn't support accessibility (specifically Orca) Status in gnome-shell-extension-desktop-icons-ng package in Ubuntu: New Bug description: [ Impact ] Currently, the Desktop Icons NG (DING) extension included in Ubuntu doesn't support integration with screen readers like Orca. This is a disadvantage for visually impaired users. Since DING is implemented as a classic GTK application, it should be easy to wire it up to make use of the accessibility functions already available thanks to the ATK library. A patch for that has been recently uploaded to upstream, after a fix for this was requested by an user. The patch takes advantage of the already implemented keyboard navigation, and just makes these little changes: * sets a readable accessible description for the Desktop Icons window (because the application uses the invisible title bar to communicate with the extension, thus it contains just "odd characters and numbers") * sets an accessible description for each icon with the type and the visible name of the file, and marks each icon as focusable * when an icon is marked as selected, it gives the focus to it, thus triggering the screen reader to read the accessible description Also, the code for keyboard navigation is moved from the "key-press" event to the "key-release" event, because that's the event used by the accessibility subsystem, and not doing this results in an incorrect icon being read by it. [ Test plan ] * Enable the Orca screen reader by pressing Mod+Alt+S. A voice will say "Screen reader enabled" (or a similar, translated message). * Click on the desktop to give the focus to it. * Press the arrow keys to navigate with the keyboard through the icons. Only one icon should be highlighted, and it should change when the arrows are moved. * After the test, the screen reader can be disabled by pressing the same keys combination. Expected results: The screen reader should say the type and name of the selected icon, every time the arrow keys are pressed to change the selected icon. Current results: The screen reader remains silent while navigating with the keyboard. [ Where problems could occur ] A change in the way GTK manages the focus could result in the keyboard navigation to work incorrectly. To manage notifications
[Desktop-packages] [Bug 1971168] Re: [snap] Files on local network shares are not opened / written
Oh, you mean if it will be backported to LTS! I'm not sure... I'll check it. (sorry, I read the numbers wrong and interpreted 24.04) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xdg-desktop-portal in Ubuntu. https://bugs.launchpad.net/bugs/1971168 Title: [snap] Files on local network shares are not opened / written Status in Mozilla Firefox: Confirmed Status in firefox package in Ubuntu: Triaged Status in xdg-desktop-portal package in Ubuntu: Triaged Status in xdg-desktop-portal-gnome package in Ubuntu: Fix Released Status in xdg-desktop-portal-gnome source package in Jammy: Triaged Status in xdg-desktop-portal-gnome source package in Lunar: Triaged Bug description: [ Impact ] When the user is running a containerized application (like the snapped Firefox or Chromium), and tries to save a document, the xdg-desktop- portal-gnome backend does show remote drives (like SMB or SFTP ones), and allows to choose them, but then the save operation fails. The previous backend, xdg-desktop-portal-gtk, did work fine in these cases, because it returned the local path that corresponded to the local file exported by Gvfs using FUSE, so this behaviour is not only a serious bug, but also a regression. [ Test plan] Steps to reproduce: 1. Run Firefox as a Snap package in Ubuntu 22.04 2. Have a SMB file server available where the network shares can be mounted just by clicking on the share in Nautilus file manager (smb:// protocol, usually mounted dynamically via `/var/run/user/.../gvfs/...`) 3. Have one such share mounted and writable 4. Open any website containing images in Firefox 5. Right-click on an image and select "Save Image As..." 6. In the file save dialog, navigate to the mounted share 7. Assert content of network share is visible and browsable from within the save dialog 8. Select "Save" at any folder in the network share Actual behavior: * File is not saved to selected network share location * No download entry is created * No error is shown Expected behavior: * File is saved to selected network share location * No error is shown [ Where problems could occur ] - If the remote drives aren't exported as local files by Gvfs using FUSE, the patch won't work and the behaviour will be the same than now. - Any hidden bug in g_file_get_path() when managing remote drives could be triggered by this patch. [ Additional information ] * When saving to a folder on the local machine instead, saving works correctly as expected * In contrast to files, new folders that are created from within the save dialog are saved correctly on the network share * Similar situation when trying to open a file with Ctrl + O on a network share from Firefox / Chromium. After double-clicking e.g. an image file in the file dialog, the file dialog closes but nothing happens otherwise. Opening an image on a local folder works fine. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1971168/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1968513] Re: GNOME login fails to stay in the overview if DING is enabled
After checking that extension, I think that I can use the same trick for DING. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell in Ubuntu. https://bugs.launchpad.net/bugs/1968513 Title: GNOME login fails to stay in the overview if DING is enabled Status in gnome-shell package in Ubuntu: Confirmed Status in gnome-shell-extension-desktop-icons-ng package in Ubuntu: Confirmed Bug description: Ubuntu 22.04 (April 9 daily, latest) If you either disable the ubuntu-dock or remove it all together. On every login after that, the Activities window appears for just a few seconds. After those few seconds the Activities window automatically closes, which exposes the desktop. What I expected to happen is no Activity window to appear on login. I just want the desktop to appear, no dock, no Activities. More or less, I'm going for a "kiosk" type of desktop. Thanks for your time! ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: gnome-shell-extension-ubuntu-dock 72~ubuntu3 ProcVersionSignature: Ubuntu 5.15.0-25.25-generic 5.15.30 Uname: Linux 5.15.0-25-generic x86_64 ApportVersion: 2.20.11-0ubuntu80 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sun Apr 10 19:42:00 2022 InstallationDate: Installed on 2022-04-11 (0 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Daily amd64 (20220409) PackageArchitecture: all ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: gnome-shell-extension-ubuntu-dock UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1968513/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1971168] Re: [snap] Files on local network shares are not opened / written
I have to check it, but probably the reason is that it still is using the current version of gnome shell, so it won't be fixed until Gnome 46 is added to the repositories. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xdg-desktop-portal in Ubuntu. https://bugs.launchpad.net/bugs/1971168 Title: [snap] Files on local network shares are not opened / written Status in Mozilla Firefox: Confirmed Status in firefox package in Ubuntu: Triaged Status in xdg-desktop-portal package in Ubuntu: Triaged Status in xdg-desktop-portal-gnome package in Ubuntu: Fix Released Status in xdg-desktop-portal-gnome source package in Jammy: Triaged Status in xdg-desktop-portal-gnome source package in Lunar: Triaged Bug description: [ Impact ] When the user is running a containerized application (like the snapped Firefox or Chromium), and tries to save a document, the xdg-desktop- portal-gnome backend does show remote drives (like SMB or SFTP ones), and allows to choose them, but then the save operation fails. The previous backend, xdg-desktop-portal-gtk, did work fine in these cases, because it returned the local path that corresponded to the local file exported by Gvfs using FUSE, so this behaviour is not only a serious bug, but also a regression. [ Test plan] Steps to reproduce: 1. Run Firefox as a Snap package in Ubuntu 22.04 2. Have a SMB file server available where the network shares can be mounted just by clicking on the share in Nautilus file manager (smb:// protocol, usually mounted dynamically via `/var/run/user/.../gvfs/...`) 3. Have one such share mounted and writable 4. Open any website containing images in Firefox 5. Right-click on an image and select "Save Image As..." 6. In the file save dialog, navigate to the mounted share 7. Assert content of network share is visible and browsable from within the save dialog 8. Select "Save" at any folder in the network share Actual behavior: * File is not saved to selected network share location * No download entry is created * No error is shown Expected behavior: * File is saved to selected network share location * No error is shown [ Where problems could occur ] - If the remote drives aren't exported as local files by Gvfs using FUSE, the patch won't work and the behaviour will be the same than now. - Any hidden bug in g_file_get_path() when managing remote drives could be triggered by this patch. [ Additional information ] * When saving to a folder on the local machine instead, saving works correctly as expected * In contrast to files, new folders that are created from within the save dialog are saved correctly on the network share * Similar situation when trying to open a file with Ctrl + O on a network share from Firefox / Chromium. After double-clicking e.g. an image file in the file dialog, the file dialog closes but nothing happens otherwise. Opening an image on a local folder works fine. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1971168/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1971168] Re: [snap] Files on local network shares are not opened / written
Yes, it should, because the patch has been merged in upstream. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xdg-desktop-portal in Ubuntu. https://bugs.launchpad.net/bugs/1971168 Title: [snap] Files on local network shares are not opened / written Status in Mozilla Firefox: Confirmed Status in firefox package in Ubuntu: Triaged Status in xdg-desktop-portal package in Ubuntu: Triaged Status in xdg-desktop-portal-gnome package in Ubuntu: Fix Released Status in xdg-desktop-portal-gnome source package in Jammy: Triaged Status in xdg-desktop-portal-gnome source package in Lunar: Triaged Bug description: [ Impact ] When the user is running a containerized application (like the snapped Firefox or Chromium), and tries to save a document, the xdg-desktop- portal-gnome backend does show remote drives (like SMB or SFTP ones), and allows to choose them, but then the save operation fails. The previous backend, xdg-desktop-portal-gtk, did work fine in these cases, because it returned the local path that corresponded to the local file exported by Gvfs using FUSE, so this behaviour is not only a serious bug, but also a regression. [ Test plan] Steps to reproduce: 1. Run Firefox as a Snap package in Ubuntu 22.04 2. Have a SMB file server available where the network shares can be mounted just by clicking on the share in Nautilus file manager (smb:// protocol, usually mounted dynamically via `/var/run/user/.../gvfs/...`) 3. Have one such share mounted and writable 4. Open any website containing images in Firefox 5. Right-click on an image and select "Save Image As..." 6. In the file save dialog, navigate to the mounted share 7. Assert content of network share is visible and browsable from within the save dialog 8. Select "Save" at any folder in the network share Actual behavior: * File is not saved to selected network share location * No download entry is created * No error is shown Expected behavior: * File is saved to selected network share location * No error is shown [ Where problems could occur ] - If the remote drives aren't exported as local files by Gvfs using FUSE, the patch won't work and the behaviour will be the same than now. - Any hidden bug in g_file_get_path() when managing remote drives could be triggered by this patch. [ Additional information ] * When saving to a folder on the local machine instead, saving works correctly as expected * In contrast to files, new folders that are created from within the save dialog are saved correctly on the network share * Similar situation when trying to open a file with Ctrl + O on a network share from Firefox / Chromium. After double-clicking e.g. an image file in the file dialog, the file dialog closes but nothing happens otherwise. Opening an image on a local folder works fine. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1971168/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1971168]
(In reply to Sergio Costas from comment #52) > The patch has landed in upstream today. I mean: it has been merged today. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xdg-desktop-portal in Ubuntu. https://bugs.launchpad.net/bugs/1971168 Title: [snap] Files on local network shares are not opened / written Status in Mozilla Firefox: Confirmed Status in firefox package in Ubuntu: Triaged Status in xdg-desktop-portal package in Ubuntu: Triaged Status in xdg-desktop-portal-gnome package in Ubuntu: Fix Released Status in xdg-desktop-portal-gnome source package in Jammy: Triaged Status in xdg-desktop-portal-gnome source package in Lunar: Triaged Bug description: [ Impact ] When the user is running a containerized application (like the snapped Firefox or Chromium), and tries to save a document, the xdg-desktop- portal-gnome backend does show remote drives (like SMB or SFTP ones), and allows to choose them, but then the save operation fails. The previous backend, xdg-desktop-portal-gtk, did work fine in these cases, because it returned the local path that corresponded to the local file exported by Gvfs using FUSE, so this behaviour is not only a serious bug, but also a regression. [ Test plan] Steps to reproduce: 1. Run Firefox or Chromium as a Snap package in Ubuntu 22.04 2. Have a SMB file server available where the network shares can be mounted just by clicking on the share in Nautilus file manager (smb:// protocol, usually mounted dynamically via `/var/run/user/.../gvfs/...`) 3. Have one such share mounted and writable 4. Open any website containing images in Firefox / Chromium 5. Right-click on an image and select "Save Image As..." 6. In the file save dialog, navigate to the mounted share 7. Assert content of network share is visible and browsable from within the save dialog 8. Select "Save" at any folder in the network share Actual behavior: * File is not saved to selected network share location * No download entry is created * No error is shown Expected behavior: * File is saved to selected network share location * No error is shown [ Where problems could occur ] - If the remote drives aren't exported as local files by Gvfs using FUSE, the patch won't work and the behaviour will be the same than now. - Any hidden bug in g_file_get_path() when managing remote drives could be triggered by this patch. [ Additional information ] * When saving to a folder on the local machine instead, saving works correctly as expected * In contrast to files, new folders that are created from within the save dialog are saved correctly on the network share * Similar situation when trying to open a file with Ctrl + O on a network share from Firefox / Chromium. After double-clicking e.g. an image file in the file dialog, the file dialog closes but nothing happens otherwise. Opening an image on a local folder works fine. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1971168/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1971168]
The patch has landed in upstream today. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xdg-desktop-portal in Ubuntu. https://bugs.launchpad.net/bugs/1971168 Title: [snap] Files on local network shares are not opened / written Status in Mozilla Firefox: Confirmed Status in firefox package in Ubuntu: Triaged Status in xdg-desktop-portal package in Ubuntu: Triaged Status in xdg-desktop-portal-gnome package in Ubuntu: Fix Released Status in xdg-desktop-portal-gnome source package in Jammy: Triaged Status in xdg-desktop-portal-gnome source package in Lunar: Triaged Bug description: [ Impact ] When the user is running a containerized application (like the snapped Firefox or Chromium), and tries to save a document, the xdg-desktop- portal-gnome backend does show remote drives (like SMB or SFTP ones), and allows to choose them, but then the save operation fails. The previous backend, xdg-desktop-portal-gtk, did work fine in these cases, because it returned the local path that corresponded to the local file exported by Gvfs using FUSE, so this behaviour is not only a serious bug, but also a regression. [ Test plan] Steps to reproduce: 1. Run Firefox or Chromium as a Snap package in Ubuntu 22.04 2. Have a SMB file server available where the network shares can be mounted just by clicking on the share in Nautilus file manager (smb:// protocol, usually mounted dynamically via `/var/run/user/.../gvfs/...`) 3. Have one such share mounted and writable 4. Open any website containing images in Firefox / Chromium 5. Right-click on an image and select "Save Image As..." 6. In the file save dialog, navigate to the mounted share 7. Assert content of network share is visible and browsable from within the save dialog 8. Select "Save" at any folder in the network share Actual behavior: * File is not saved to selected network share location * No download entry is created * No error is shown Expected behavior: * File is saved to selected network share location * No error is shown [ Where problems could occur ] - If the remote drives aren't exported as local files by Gvfs using FUSE, the patch won't work and the behaviour will be the same than now. - Any hidden bug in g_file_get_path() when managing remote drives could be triggered by this patch. [ Additional information ] * When saving to a folder on the local machine instead, saving works correctly as expected * In contrast to files, new folders that are created from within the save dialog are saved correctly on the network share * Similar situation when trying to open a file with Ctrl + O on a network share from Firefox / Chromium. After double-clicking e.g. an image file in the file dialog, the file dialog closes but nothing happens otherwise. Opening an image on a local folder works fine. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1971168/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1971168] Re: [snap] Files on local network shares are not opened / written
The patch has been merged, and also has been backported to GNOME 45, so it is possible that it can make it to Mantic. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xdg-desktop-portal in Ubuntu. https://bugs.launchpad.net/bugs/1971168 Title: [snap] Files on local network shares are not opened / written Status in Mozilla Firefox: Confirmed Status in firefox package in Ubuntu: Triaged Status in xdg-desktop-portal package in Ubuntu: Triaged Status in xdg-desktop-portal-gnome package in Ubuntu: Fix Released Status in xdg-desktop-portal-gnome source package in Jammy: Triaged Status in xdg-desktop-portal-gnome source package in Lunar: Triaged Bug description: [ Impact ] When the user is running a containerized application (like the snapped Firefox or Chromium), and tries to save a document, the xdg-desktop- portal-gnome backend does show remote drives (like SMB or SFTP ones), and allows to choose them, but then the save operation fails. The previous backend, xdg-desktop-portal-gtk, did work fine in these cases, because it returned the local path that corresponded to the local file exported by Gvfs using FUSE, so this behaviour is not only a serious bug, but also a regression. [ Test plan] Steps to reproduce: 1. Run Firefox or Chromium as a Snap package in Ubuntu 22.04 2. Have a SMB file server available where the network shares can be mounted just by clicking on the share in Nautilus file manager (smb:// protocol, usually mounted dynamically via `/var/run/user/.../gvfs/...`) 3. Have one such share mounted and writable 4. Open any website containing images in Firefox / Chromium 5. Right-click on an image and select "Save Image As..." 6. In the file save dialog, navigate to the mounted share 7. Assert content of network share is visible and browsable from within the save dialog 8. Select "Save" at any folder in the network share Actual behavior: * File is not saved to selected network share location * No download entry is created * No error is shown Expected behavior: * File is saved to selected network share location * No error is shown [ Where problems could occur ] - If the remote drives aren't exported as local files by Gvfs using FUSE, the patch won't work and the behaviour will be the same than now. - Any hidden bug in g_file_get_path() when managing remote drives could be triggered by this patch. [ Additional information ] * When saving to a folder on the local machine instead, saving works correctly as expected * In contrast to files, new folders that are created from within the save dialog are saved correctly on the network share * Similar situation when trying to open a file with Ctrl + O on a network share from Firefox / Chromium. After double-clicking e.g. an image file in the file dialog, the file dialog closes but nothing happens otherwise. Opening an image on a local folder works fine. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1971168/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1971168] Re: [snap] Files on local network shares are not opened / written
The patch for xdg-desktop-portal-gnome is continuing its way towards being mainlined: https://gitlab.gnome.org/GNOME/xdg-desktop-portal- gnome/-/merge_requests/67 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xdg-desktop-portal in Ubuntu. https://bugs.launchpad.net/bugs/1971168 Title: [snap] Files on local network shares are not opened / written Status in Mozilla Firefox: Confirmed Status in firefox package in Ubuntu: Triaged Status in xdg-desktop-portal package in Ubuntu: Triaged Status in xdg-desktop-portal-gnome package in Ubuntu: Fix Released Status in xdg-desktop-portal-gnome source package in Jammy: Triaged Status in xdg-desktop-portal-gnome source package in Lunar: Triaged Bug description: [ Impact ] When the user is running a containerized application (like the snapped Firefox or Chromium), and tries to save a document, the xdg-desktop- portal-gnome backend does show remote drives (like SMB or SFTP ones), and allows to choose them, but then the save operation fails. The previous backend, xdg-desktop-portal-gtk, did work fine in these cases, because it returned the local path that corresponded to the local file exported by Gvfs using FUSE, so this behaviour is not only a serious bug, but also a regression. [ Test plan] Steps to reproduce: 1. Run Firefox or Chromium as a Snap package in Ubuntu 22.04 2. Have a SMB file server available where the network shares can be mounted just by clicking on the share in Nautilus file manager (smb:// protocol, usually mounted dynamically via `/var/run/user/.../gvfs/...`) 3. Have one such share mounted and writable 4. Open any website containing images in Firefox / Chromium 5. Right-click on an image and select "Save Image As..." 6. In the file save dialog, navigate to the mounted share 7. Assert content of network share is visible and browsable from within the save dialog 8. Select "Save" at any folder in the network share Actual behavior: * File is not saved to selected network share location * No download entry is created * No error is shown Expected behavior: * File is saved to selected network share location * No error is shown [ Where problems could occur ] - If the remote drives aren't exported as local files by Gvfs using FUSE, the patch won't work and the behaviour will be the same than now. - Any hidden bug in g_file_get_path() when managing remote drives could be triggered by this patch. [ Additional information ] * When saving to a folder on the local machine instead, saving works correctly as expected * In contrast to files, new folders that are created from within the save dialog are saved correctly on the network share * Similar situation when trying to open a file with Ctrl + O on a network share from Firefox / Chromium. After double-clicking e.g. an image file in the file dialog, the file dialog closes but nothing happens otherwise. Opening an image on a local folder works fine. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1971168/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1971168]
That's right. I'm working on landing this on upstream. As commented, the problem is in xdg-desktop-portal-gnome. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xdg-desktop-portal in Ubuntu. https://bugs.launchpad.net/bugs/1971168 Title: [snap] Files on local network shares are not opened / written Status in Mozilla Firefox: Confirmed Status in firefox package in Ubuntu: Triaged Status in xdg-desktop-portal package in Ubuntu: Triaged Status in xdg-desktop-portal-gnome package in Ubuntu: Fix Released Status in xdg-desktop-portal-gnome source package in Jammy: Triaged Status in xdg-desktop-portal-gnome source package in Lunar: Triaged Bug description: [ Impact ] When the user is running a containerized application (like the snapped Firefox or Chromium), and tries to save a document, the xdg-desktop- portal-gnome backend does show remote drives (like SMB or SFTP ones), and allows to choose them, but then the save operation fails. The previous backend, xdg-desktop-portal-gtk, did work fine in these cases, because it returned the local path that corresponded to the local file exported by Gvfs using FUSE, so this behaviour is not only a serious bug, but also a regression. [ Test plan] Steps to reproduce: 1. Run Firefox or Chromium as a Snap package in Ubuntu 22.04 2. Have a SMB file server available where the network shares can be mounted just by clicking on the share in Nautilus file manager (smb:// protocol, usually mounted dynamically via `/var/run/user/.../gvfs/...`) 3. Have one such share mounted and writable 4. Open any website containing images in Firefox / Chromium 5. Right-click on an image and select "Save Image As..." 6. In the file save dialog, navigate to the mounted share 7. Assert content of network share is visible and browsable from within the save dialog 8. Select "Save" at any folder in the network share Actual behavior: * File is not saved to selected network share location * No download entry is created * No error is shown Expected behavior: * File is saved to selected network share location * No error is shown [ Where problems could occur ] - If the remote drives aren't exported as local files by Gvfs using FUSE, the patch won't work and the behaviour will be the same than now. - Any hidden bug in g_file_get_path() when managing remote drives could be triggered by this patch. [ Additional information ] * When saving to a folder on the local machine instead, saving works correctly as expected * In contrast to files, new folders that are created from within the save dialog are saved correctly on the network share * Similar situation when trying to open a file with Ctrl + O on a network share from Firefox / Chromium. After double-clicking e.g. an image file in the file dialog, the file dialog closes but nothing happens otherwise. Opening an image on a local folder works fine. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1971168/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2039475] Re: Desktop icons in Mantic doesn't honor dock margins
This patch fixes the problem. ** Patch added: "patch.diff" https://bugs.launchpad.net/ubuntu/+source/gnome-shell-extension-desktop-icons/+bug/2039475/+attachment/5709973/+files/patch.diff -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-desktop-icons in Ubuntu. https://bugs.launchpad.net/bugs/2039475 Title: Desktop icons in Mantic doesn't honor dock margins Status in gnome-shell-extension-desktop-icons package in Ubuntu: New Bug description: The port to Gnome Shell 45 of Desktop Icons had a bug that prevents it from honoring the Dock size when in "IntelliHide" mode, thus allowing to put icons under it. This bug has been fixed in upstream, so it should be ported to Mantic. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell-extension-desktop-icons/+bug/2039475/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2039475] [NEW] Desktop icons in Mantic doesn't honor dock margins
Public bug reported: The port to Gnome Shell 45 of Desktop Icons had a bug that prevents it from honoring the Dock size when in "IntelliHide" mode, thus allowing to put icons under it. This bug has been fixed in upstream, so it should be ported to Mantic. ** Affects: gnome-shell-extension-desktop-icons (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-desktop-icons in Ubuntu. https://bugs.launchpad.net/bugs/2039475 Title: Desktop icons in Mantic doesn't honor dock margins Status in gnome-shell-extension-desktop-icons package in Ubuntu: New Bug description: The port to Gnome Shell 45 of Desktop Icons had a bug that prevents it from honoring the Dock size when in "IntelliHide" mode, thus allowing to put icons under it. This bug has been fixed in upstream, so it should be ported to Mantic. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell-extension-desktop-icons/+bug/2039475/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1971168] Re: [snap] Files on local network shares are not opened / written
** Description changed: + Impact: + + When the user is running a containerized application (like the snapped + Firefox or Chromium), and tries to save a document, the xdg-desktop- + portal-gnome backend does show remote drives (like SMB or SFTP ones), + and allows to choose them, but then the save operation fails. + + The previous backend, xdg-desktop-portal-gtk, did work fine in these + cases, because it returned the local path that corresponded to the local + file exported by Gvfs using FUSE, so this behaviour is not only a + serious bug, but also a regression. + + [ Test plan] Steps to reproduce: 1. Run Firefox or Chromium as a Snap package in Ubuntu 22.04 2. Have a SMB file server available where the network shares can be mounted just by clicking on the share in Nautilus file manager (smb:// protocol, usually mounted dynamically via `/var/run/user/.../gvfs/...`) 3. Have one such share mounted and writable 4. Open any website containing images in Firefox / Chromium 5. Right-click on an image and select "Save Image As..." 6. In the file save dialog, navigate to the mounted share 7. Assert content of network share is visible and browsable from within the save dialog 8. Select "Save" at any folder in the network share Actual behavior: * File is not saved to selected network share location * No download entry is created * No error is shown Expected behavior: * File is saved to selected network share location * No error is shown - Additional information: + [ Where problems could occur ] + + - If the remote drives aren't exported as local files by Gvfs using + FUSE, the patch won't work and the behaviour will be the same than now. + + - Any hidden bug in g_file_get_path() when managing remote drives could + be triggered by this patch. + + [ Additional information ] * When saving to a folder on the local machine instead, saving works correctly as expected * In contrast to files, new folders that are created from within the save dialog are saved correctly on the network share * Similar situation when trying to open a file with Ctrl + O on a network share from Firefox / Chromium. After double-clicking e.g. an image file in the file dialog, the file dialog closes but nothing happens otherwise. Opening an image on a local folder works fine. ** Description changed: - Impact: + [ Impact ] When the user is running a containerized application (like the snapped Firefox or Chromium), and tries to save a document, the xdg-desktop- portal-gnome backend does show remote drives (like SMB or SFTP ones), and allows to choose them, but then the save operation fails. The previous backend, xdg-desktop-portal-gtk, did work fine in these cases, because it returned the local path that corresponded to the local file exported by Gvfs using FUSE, so this behaviour is not only a serious bug, but also a regression. [ Test plan] Steps to reproduce: 1. Run Firefox or Chromium as a Snap package in Ubuntu 22.04 2. Have a SMB file server available where the network shares can be mounted just by clicking on the share in Nautilus file manager (smb:// protocol, usually mounted dynamically via `/var/run/user/.../gvfs/...`) 3. Have one such share mounted and writable 4. Open any website containing images in Firefox / Chromium 5. Right-click on an image and select "Save Image As..." 6. In the file save dialog, navigate to the mounted share 7. Assert content of network share is visible and browsable from within the save dialog 8. Select "Save" at any folder in the network share Actual behavior: * File is not saved to selected network share location * No download entry is created * No error is shown Expected behavior: * File is saved to selected network share location * No error is shown [ Where problems could occur ] - If the remote drives aren't exported as local files by Gvfs using FUSE, the patch won't work and the behaviour will be the same than now. - Any hidden bug in g_file_get_path() when managing remote drives could be triggered by this patch. [ Additional information ] * When saving to a folder on the local machine instead, saving works correctly as expected * In contrast to files, new folders that are created from within the save dialog are saved correctly on the network share * Similar situation when trying to open a file with Ctrl + O on a network share from Firefox / Chromium. After double-clicking e.g. an image file in the file dialog, the file dialog closes but nothing happens otherwise. Opening an image on a local folder works fine. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xdg-desktop-portal in Ubuntu. https://bugs.launchpad.net/bugs/1971168 Title: [snap] Files on local network shares are not opened / written Status in Mozilla Firefox: Confirmed Status in firefox
[Desktop-packages] [Bug 1971168]
The patch is sent, but it seems that there were some changes in the maintainers of xdg-desktop-portal-gnome, so I suspect that it will need some time until it is merged upstream... :-( -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xdg-desktop-portal in Ubuntu. https://bugs.launchpad.net/bugs/1971168 Title: [snap] Files on local network shares are not opened / written Status in Mozilla Firefox: Confirmed Status in firefox package in Ubuntu: Triaged Status in xdg-desktop-portal package in Ubuntu: Triaged Bug description: Steps to reproduce: 1. Run Firefox or Chromium as a Snap package in Ubuntu 22.04 2. Have a SMB file server available where the network shares can be mounted just by clicking on the share in Nautilus file manager (smb:// protocol, usually mounted dynamically via `/var/run/user/.../gvfs/...`) 3. Have one such share mounted and writable 4. Open any website containing images in Firefox / Chromium 5. Right-click on an image and select "Save Image As..." 6. In the file save dialog, navigate to the mounted share 7. Assert content of network share is visible and browsable from within the save dialog 8. Select "Save" at any folder in the network share Actual behavior: * File is not saved to selected network share location * No download entry is created * No error is shown Expected behavior: * File is saved to selected network share location * No error is shown Additional information: * When saving to a folder on the local machine instead, saving works correctly as expected * In contrast to files, new folders that are created from within the save dialog are saved correctly on the network share * Similar situation when trying to open a file with Ctrl + O on a network share from Firefox / Chromium. After double-clicking e.g. an image file in the file dialog, the file dialog closes but nothing happens otherwise. Opening an image on a local folder works fine. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1971168/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1971168]
(In reply to Alexandre LISSY :gerard-majax from comment #44) > Sergio, I applied the patch locally on `xdg-desktop-portal-gnome` package, > and it is fixing the issue. Thanks! -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xdg-desktop-portal in Ubuntu. https://bugs.launchpad.net/bugs/1971168 Title: [snap] Files on local network shares are not opened / written Status in Mozilla Firefox: Confirmed Status in firefox package in Ubuntu: Triaged Status in xdg-desktop-portal package in Ubuntu: Triaged Bug description: Steps to reproduce: 1. Run Firefox or Chromium as a Snap package in Ubuntu 22.04 2. Have a SMB file server available where the network shares can be mounted just by clicking on the share in Nautilus file manager (smb:// protocol, usually mounted dynamically via `/var/run/user/.../gvfs/...`) 3. Have one such share mounted and writable 4. Open any website containing images in Firefox / Chromium 5. Right-click on an image and select "Save Image As..." 6. In the file save dialog, navigate to the mounted share 7. Assert content of network share is visible and browsable from within the save dialog 8. Select "Save" at any folder in the network share Actual behavior: * File is not saved to selected network share location * No download entry is created * No error is shown Expected behavior: * File is saved to selected network share location * No error is shown Additional information: * When saving to a folder on the local machine instead, saving works correctly as expected * In contrast to files, new folders that are created from within the save dialog are saved correctly on the network share * Similar situation when trying to open a file with Ctrl + O on a network share from Firefox / Chromium. After double-clicking e.g. an image file in the file dialog, the file dialog closes but nothing happens otherwise. Opening an image on a local folder works fine. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1971168/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1971168]
> > Have you tested the new patch? > Sorry, I was on leave, is testing the patch still required ? It would be great if you can test it. In fact, I've been working on it yesterday and today, doing some changes requested by Bastien. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xdg-desktop-portal in Ubuntu. https://bugs.launchpad.net/bugs/1971168 Title: [snap] Files on local network shares are not opened / written Status in Mozilla Firefox: Confirmed Status in firefox package in Ubuntu: Triaged Status in xdg-desktop-portal package in Ubuntu: Triaged Bug description: Steps to reproduce: 1. Run Firefox or Chromium as a Snap package in Ubuntu 22.04 2. Have a SMB file server available where the network shares can be mounted just by clicking on the share in Nautilus file manager (smb:// protocol, usually mounted dynamically via `/var/run/user/.../gvfs/...`) 3. Have one such share mounted and writable 4. Open any website containing images in Firefox / Chromium 5. Right-click on an image and select "Save Image As..." 6. In the file save dialog, navigate to the mounted share 7. Assert content of network share is visible and browsable from within the save dialog 8. Select "Save" at any folder in the network share Actual behavior: * File is not saved to selected network share location * No download entry is created * No error is shown Expected behavior: * File is saved to selected network share location * No error is shown Additional information: * When saving to a folder on the local machine instead, saving works correctly as expected * In contrast to files, new folders that are created from within the save dialog are saved correctly on the network share * Similar situation when trying to open a file with Ctrl + O on a network share from Firefox / Chromium. After double-clicking e.g. an image file in the file dialog, the file dialog closes but nothing happens otherwise. Opening an image on a local folder works fine. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1971168/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1971168]
I discovered a simpler way of fixing this. I sent this patch for XDG- desktop-portal-gnome. https://gitlab.gnome.org/GNOME/xdg-desktop-portal- gnome/-/merge_requests/67 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xdg-desktop-portal in Ubuntu. https://bugs.launchpad.net/bugs/1971168 Title: [snap] Files on local network shares are not opened / written Status in Mozilla Firefox: Confirmed Status in firefox package in Ubuntu: Triaged Status in xdg-desktop-portal package in Ubuntu: Triaged Bug description: Steps to reproduce: 1. Run Firefox or Chromium as a Snap package in Ubuntu 22.04 2. Have a SMB file server available where the network shares can be mounted just by clicking on the share in Nautilus file manager (smb:// protocol, usually mounted dynamically via `/var/run/user/.../gvfs/...`) 3. Have one such share mounted and writable 4. Open any website containing images in Firefox / Chromium 5. Right-click on an image and select "Save Image As..." 6. In the file save dialog, navigate to the mounted share 7. Assert content of network share is visible and browsable from within the save dialog 8. Select "Save" at any folder in the network share Actual behavior: * File is not saved to selected network share location * No download entry is created * No error is shown Expected behavior: * File is saved to selected network share location * No error is shown Additional information: * When saving to a folder on the local machine instead, saving works correctly as expected * In contrast to files, new folders that are created from within the save dialog are saved correctly on the network share * Similar situation when trying to open a file with Ctrl + O on a network share from Firefox / Chromium. After double-clicking e.g. an image file in the file dialog, the file dialog closes but nothing happens otherwise. Opening an image on a local folder works fine. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1971168/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1971168]
(In reply to Alexandre LISSY :gerard-majax [PTO 12/12/2022-28/02/2023] from comment #38) > (In reply to tc from comment #37) > > What's the overview of this ? It seems like it would solve a problem of > > "can't save there" in a general way ? > > > > Still blocked on upstream ... Have you tested the new patch? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xdg-desktop-portal in Ubuntu. https://bugs.launchpad.net/bugs/1971168 Title: [snap] Files on local network shares are not opened / written Status in Mozilla Firefox: Confirmed Status in firefox package in Ubuntu: Triaged Status in xdg-desktop-portal package in Ubuntu: Triaged Bug description: Steps to reproduce: 1. Run Firefox or Chromium as a Snap package in Ubuntu 22.04 2. Have a SMB file server available where the network shares can be mounted just by clicking on the share in Nautilus file manager (smb:// protocol, usually mounted dynamically via `/var/run/user/.../gvfs/...`) 3. Have one such share mounted and writable 4. Open any website containing images in Firefox / Chromium 5. Right-click on an image and select "Save Image As..." 6. In the file save dialog, navigate to the mounted share 7. Assert content of network share is visible and browsable from within the save dialog 8. Select "Save" at any folder in the network share Actual behavior: * File is not saved to selected network share location * No download entry is created * No error is shown Expected behavior: * File is saved to selected network share location * No error is shown Additional information: * When saving to a folder on the local machine instead, saving works correctly as expected * In contrast to files, new folders that are created from within the save dialog are saved correctly on the network share * Similar situation when trying to open a file with Ctrl + O on a network share from Firefox / Chromium. After double-clicking e.g. an image file in the file dialog, the file dialog closes but nothing happens otherwise. Opening an image on a local folder works fine. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1971168/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1779890] Re: Nautilus does not use a valid Kerberos ticket when accessing Samba share
I found something odd... Setting KRB5CCNAME in /etc/environment does work, but setting "default_ccache_name" in /etc/krb5.conf doesn't. In theory, when KRB5CCNAME isn't set, kerberos should use that value for the cache file. And although the command line tools do use it, it seems that gvfsd doesn't... -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gvfs in Ubuntu. https://bugs.launchpad.net/bugs/1779890 Title: Nautilus does not use a valid Kerberos ticket when accessing Samba share Status in gvfs: New Status in gvfs package in Ubuntu: Triaged Bug description: Nautilus prompts for username and password when accessing a Samba share on a network drive, despite having a perfectly valid unexpired Kerberos ticket. The Kerberos ticket is obtained automatically at logon by authentication against a Samba Active Directory server (Samba AD-DC). Accessing the same Samba share with the same Kerberos ticket via "smbclient //host/sharename -k" works fine. One known workaround is: "nautilus -q", and then "killall gvfsd". After that, accessing the Samba share with Nautilus works normally as it should. I did not experience this issue in Ubuntu 16.04. It appears that a regression was introduced somewhere between 16.04 and 18.04. The issue is quite annoying and confusing for the users who are used to accessing Samba shares on the network drive without being prompted for their username and password. The issue appears to manifest itself usually not on the first access to a Samba share, but on subsequent accesses after a system reboot or upon user logout/login. Strangely, removing ~/.cache/ibus/bus/registry file before user login appears to fix the issue for the current user session, but then the problem reappears upon subsequent user logins or after a system reboot. Nemo appears to have the same problem as Nautilus. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gvfs-daemons 1.36.1-0ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-24.26-generic 4.15.18 Uname: Linux 4.15.0-24-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 Date: Tue Jul 3 11:12:06 2018 ExecutablePath: /usr/lib/gvfs/gvfsd InstallationDate: Installed on 2018-04-27 (66 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) ProcEnviron: LANG=en_CA.UTF-8 PATH=(custom, no user) SHELL=/bin/bash XDG_RUNTIME_DIR= SourcePackage: gvfs UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/gvfs/+bug/1779890/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1779890] Re: Nautilus does not use a valid Kerberos ticket when accessing Samba share
If you try my line, be sure to create the folder ~/kerberos before, so
maybe a better alternative would be the line
KRB5CCNAME=${HOME}/.config/krb5cc_${LOGNAME}
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1779890
Title:
Nautilus does not use a valid Kerberos ticket when accessing Samba
share
Status in gvfs:
New
Status in gvfs package in Ubuntu:
Triaged
Bug description:
Nautilus prompts for username and password when accessing a Samba
share on a network drive, despite having a perfectly valid unexpired
Kerberos ticket. The Kerberos ticket is obtained automatically at
logon by authentication against a Samba Active Directory server (Samba
AD-DC).
Accessing the same Samba share with the same Kerberos ticket via
"smbclient //host/sharename -k" works fine.
One known workaround is: "nautilus -q", and then "killall gvfsd".
After that, accessing the Samba share with Nautilus works normally as
it should.
I did not experience this issue in Ubuntu 16.04. It appears that a
regression was introduced somewhere between 16.04 and 18.04.
The issue is quite annoying and confusing for the users who are used
to accessing Samba shares on the network drive without being prompted
for their username and password.
The issue appears to manifest itself usually not on the first access
to a Samba share, but on subsequent accesses after a system reboot or
upon user logout/login. Strangely, removing ~/.cache/ibus/bus/registry
file before user login appears to fix the issue for the current user
session, but then the problem reappears upon subsequent user logins or
after a system reboot.
Nemo appears to have the same problem as Nautilus.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: gvfs-daemons 1.36.1-0ubuntu1
ProcVersionSignature: Ubuntu 4.15.0-24.26-generic 4.15.18
Uname: Linux 4.15.0-24-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
Date: Tue Jul 3 11:12:06 2018
ExecutablePath: /usr/lib/gvfs/gvfsd
InstallationDate: Installed on 2018-04-27 (66 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
ProcEnviron:
LANG=en_CA.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
XDG_RUNTIME_DIR=
SourcePackage: gvfs
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/gvfs/+bug/1779890/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1779890] Re: Nautilus does not use a valid Kerberos ticket when accessing Samba share
I found a workaround for this: to define the KRB5CCNAME environment
variable at /etc/environment.d/91kerberos.conf
In my case, I store the cache file at ~/kerberos, so I set the content
of that file to:
KRB5CCNAME=${HOME}/kerberos/krb5cc_${LOGNAME}
So, if my username is "username", this results in the environment
variable set to
/home/username/kerberos/krb5cc_username
After doing this, the tickets are preserved between reboots.
Can anybody test this to ensure that it fixes the problem, please?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1779890
Title:
Nautilus does not use a valid Kerberos ticket when accessing Samba
share
Status in gvfs:
New
Status in gvfs package in Ubuntu:
Triaged
Bug description:
Nautilus prompts for username and password when accessing a Samba
share on a network drive, despite having a perfectly valid unexpired
Kerberos ticket. The Kerberos ticket is obtained automatically at
logon by authentication against a Samba Active Directory server (Samba
AD-DC).
Accessing the same Samba share with the same Kerberos ticket via
"smbclient //host/sharename -k" works fine.
One known workaround is: "nautilus -q", and then "killall gvfsd".
After that, accessing the Samba share with Nautilus works normally as
it should.
I did not experience this issue in Ubuntu 16.04. It appears that a
regression was introduced somewhere between 16.04 and 18.04.
The issue is quite annoying and confusing for the users who are used
to accessing Samba shares on the network drive without being prompted
for their username and password.
The issue appears to manifest itself usually not on the first access
to a Samba share, but on subsequent accesses after a system reboot or
upon user logout/login. Strangely, removing ~/.cache/ibus/bus/registry
file before user login appears to fix the issue for the current user
session, but then the problem reappears upon subsequent user logins or
after a system reboot.
Nemo appears to have the same problem as Nautilus.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: gvfs-daemons 1.36.1-0ubuntu1
ProcVersionSignature: Ubuntu 4.15.0-24.26-generic 4.15.18
Uname: Linux 4.15.0-24-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
Date: Tue Jul 3 11:12:06 2018
ExecutablePath: /usr/lib/gvfs/gvfsd
InstallationDate: Installed on 2018-04-27 (66 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
ProcEnviron:
LANG=en_CA.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
XDG_RUNTIME_DIR=
SourcePackage: gvfs
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/gvfs/+bug/1779890/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1855711] Re: Add keyboard navigation to desktop icons
This is fixed in the upstream version; as soon as it's ported to Ubuntu, it will work. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-ubuntu-dock in Ubuntu. https://bugs.launchpad.net/bugs/1855711 Title: Add keyboard navigation to desktop icons Status in gnome-shell-extension-desktop-icons: New Status in Gnome Shell Extension Desktop Icons Ng: Fix Released Status in gnome-shell package in Ubuntu: Triaged Status in gnome-shell-extension-desktop-icons package in Ubuntu: Confirmed Status in gnome-shell-extension-desktop-icons-ng package in Ubuntu: Fix Released Status in gnome-shell-extension-ubuntu-dock package in Ubuntu: Confirmed Bug description: Pressing tab does not allow the user to select UI elements. If tab is pressed "Activities" should be selected. Left or right arrow to select items on Activities bar. If tab is pressed again, select top icon on Dock. Press down arrow to navigate down the dock. Press enter to start app. If tab is pressed instead of enter, Desktop icons should be selected. To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell-extension-desktop-icons/+bug/1855711/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2003104] Re: gnome-terminal transparency ignored in full screen mode
Yes, it is. I tested it in a VM, and can reproduce it. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to mutter in Ubuntu. https://bugs.launchpad.net/bugs/2003104 Title: gnome-terminal transparency ignored in full screen mode Status in mutter package in Ubuntu: Confirmed Bug description: Ubuntu 23.04 running wayland gnome-terminal 3.46.7-1ubuntu1 In gnome-terminal, I have set the transparency to some amount. When I go to full screen (F11), the transparency is lost and the default transparency is used. When I exit full screen, the transparency comes back and I can see in the profile settings that the transparency has not changed. It seems that tranparency was accidentally removed, and then re-added via https://git.launchpad.net/ubuntu/+source/gnome-terminal/tree/debian/patches/0001-Restore-transparency.patch?h=applied/ubuntu/lunar-devel However, maybe something was missed with regards to full screen. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/2003104/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2003104] Re: Transparency ignored in full screen mode
It's not random, at least in my system. Also, the tricks in that bug report don't work: I tried changing the transparency value, disabling and enabling again, but no dice. If I had to bet, I would say that the problem is in the fullscreen redirection to avoid composition overload with games... but I don't know if Wayland has that... -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/2003104 Title: Transparency ignored in full screen mode Status in gnome-terminal package in Ubuntu: Confirmed Bug description: Ubuntu 23.04 running wayland gnome-terminal 3.46.7-1ubuntu1 In gnome-terminal, I have set the transparency to some amount. When I go to full screen (F11), the transparency is lost and the default transparency is used. When I exit full screen, the transparency comes back and I can see in the profile settings that the transparency has not changed. It seems that tranparency was accidentally removed, and then re-added via https://git.launchpad.net/ubuntu/+source/gnome-terminal/tree/debian/patches/0001-Restore-transparency.patch?h=applied/ubuntu/lunar-devel However, maybe something was missed with regards to full screen. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2003104/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2003104] Re: Transparency ignored in full screen mode
Confirmed that this happens when libmutter/mutter-common are updated to version 11. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/2003104 Title: Transparency ignored in full screen mode Status in gnome-terminal package in Ubuntu: Confirmed Bug description: Ubuntu 23.04 running wayland gnome-terminal 3.46.7-1ubuntu1 In gnome-terminal, I have set the transparency to some amount. When I go to full screen (F11), the transparency is lost and the default transparency is used. When I exit full screen, the transparency comes back and I can see in the profile settings that the transparency has not changed. It seems that tranparency was accidentally removed, and then re-added via https://git.launchpad.net/ubuntu/+source/gnome-terminal/tree/debian/patches/0001-Restore-transparency.patch?h=applied/ubuntu/lunar-devel However, maybe something was missed with regards to full screen. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2003104/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2003104] Re: Transparency ignored in full screen mode
Installing a fresh install of Lunar, everything works fine. Updating Gtk3, LibVTE, Cairo and other libraries doesn't make it fail. But doing a dist-upgrade makes it fail like described. There is no new version neither of Gnome Terminal, nor of Gnome Shell, so it doesn't seem a problem there. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/2003104 Title: Transparency ignored in full screen mode Status in gnome-terminal package in Ubuntu: New Bug description: Ubuntu 23.04 running wayland gnome-terminal 3.46.7-1ubuntu1 In gnome-terminal, I have set the transparency to some amount. When I go to full screen (F11), the transparency is lost and the default transparency is used. When I exit full screen, the transparency comes back and I can see in the profile settings that the transparency has not changed. It seems that tranparency was accidentally removed, and then re-added via https://git.launchpad.net/ubuntu/+source/gnome-terminal/tree/debian/patches/0001-Restore-transparency.patch?h=applied/ubuntu/lunar-devel However, maybe something was missed with regards to full screen. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/2003104/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1855711] Re: Add keyboard navigation to desktop icons
Oh... :-( -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-ubuntu-dock in Ubuntu. https://bugs.launchpad.net/bugs/1855711 Title: Add keyboard navigation to desktop icons Status in gnome-shell-extension-desktop-icons: New Status in Gnome Shell Extension Desktop Icons Ng: Fix Released Status in gnome-shell package in Ubuntu: Confirmed Status in gnome-shell-extension-desktop-icons package in Ubuntu: Confirmed Status in gnome-shell-extension-desktop-icons-ng package in Ubuntu: Fix Committed Status in gnome-shell-extension-ubuntu-dock package in Ubuntu: Confirmed Bug description: Pressing tab does not allow the user to select UI elements. If tab is pressed "Activities" should be selected. Left or right arrow to select items on Activities bar. If tab is pressed again, select top icon on Dock. Press down arrow to navigate down the dock. Press enter to start app. If tab is pressed instead of enter, Desktop icons should be selected. To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell-extension-desktop-icons/+bug/1855711/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1971168]
Sorry for the delay. We are ATM working on trying to find a solution for that review. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xdg-desktop-portal in Ubuntu. https://bugs.launchpad.net/bugs/1971168 Title: [snap] Files on local network shares are not opened / written Status in Mozilla Firefox: Confirmed Status in firefox package in Ubuntu: Triaged Status in xdg-desktop-portal package in Ubuntu: Triaged Bug description: Steps to reproduce: 1. Run Firefox or Chromium as a Snap package in Ubuntu 22.04 2. Have a SMB file server available where the network shares can be mounted just by clicking on the share in Nautilus file manager (smb:// protocol, usually mounted dynamically via `/var/run/user/.../gvfs/...`) 3. Have one such share mounted and writable 4. Open any website containing images in Firefox / Chromium 5. Right-click on an image and select "Save Image As..." 6. In the file save dialog, navigate to the mounted share 7. Assert content of network share is visible and browsable from within the save dialog 8. Select "Save" at any folder in the network share Actual behavior: * File is not saved to selected network share location * No download entry is created * No error is shown Expected behavior: * File is saved to selected network share location * No error is shown Additional information: * When saving to a folder on the local machine instead, saving works correctly as expected * In contrast to files, new folders that are created from within the save dialog are saved correctly on the network share * Similar situation when trying to open a file with Ctrl + O on a network share from Firefox / Chromium. After double-clicking e.g. an image file in the file dialog, the file dialog closes but nothing happens otherwise. Opening an image on a local folder works fine. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1971168/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1978331] [NEW] DING shows several errors when no monitor is attached
Public bug reported: Recent version of gnome shell or extension has been emitting large numbers of identical, or quote similar, entries in the system journal, when the monitor is turned off or physically disconnected. The error is: DING: (gjs:10210): Gdk-CRITICAL **: 09:58:45.854: gdk_monitor_get_scale_factor: assertion 'GDK_IS_MONITOR (monitor)' failed ** Affects: gnome-shell-extension-desktop-icons-ng (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-desktop-icons-ng in Ubuntu. https://bugs.launchpad.net/bugs/1978331 Title: DING shows several errors when no monitor is attached Status in gnome-shell-extension-desktop-icons-ng package in Ubuntu: New Bug description: Recent version of gnome shell or extension has been emitting large numbers of identical, or quote similar, entries in the system journal, when the monitor is turned off or physically disconnected. The error is: DING: (gjs:10210): Gdk-CRITICAL **: 09:58:45.854: gdk_monitor_get_scale_factor: assertion 'GDK_IS_MONITOR (monitor)' failed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell-extension-desktop-icons-ng/+bug/1978331/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1978330] [NEW] Extension does odd things when other extension is disabled
Public bug reported: When an extension that was enabled before DING is disabled, the desktop with the icons stops behaving like a desktop, and instead they behave like a transparent window that can be over other windows, be moved by pressing the "Windows" key, and so on. ** Affects: gnome-shell-extension-desktop-icons-ng (Ubuntu) Importance: Undecided Assignee: Sergio Costas (rastersoft-gmail) Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-desktop-icons-ng in Ubuntu. https://bugs.launchpad.net/bugs/1978330 Title: Extension does odd things when other extension is disabled Status in gnome-shell-extension-desktop-icons-ng package in Ubuntu: New Bug description: When an extension that was enabled before DING is disabled, the desktop with the icons stops behaving like a desktop, and instead they behave like a transparent window that can be over other windows, be moved by pressing the "Windows" key, and so on. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell-extension-desktop-icons-ng/+bug/1978330/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1886322] Re: Unable to move all selected files on desktop
This should be already fixed. Can we close this? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-desktop-icons in Ubuntu. https://bugs.launchpad.net/bugs/1886322 Title: Unable to move all selected files on desktop Status in gnome-shell-extension-desktop-icons: Unknown Status in gnome-shell-extension-desktop-icons package in Ubuntu: In Progress Status in gnome-shell-extension-desktop-icons-ng package in Ubuntu: Fix Released Bug description: Hi, This bug started to happen like 1-2 months ago, and as I remember I didn't do any customizations like installing any external plugins and etc, but I have some stuff already like custom icons, shell, theme... but it worked normaly before. What is happening is that when I select more than 1 file on desktop, no matter which file it is (folder, .txt, image.. anything), and when I try to move around desktop from one place to another, it will move only 1 file and not the rest. So, unable to move selected files on desktop (drag and drop using cursor's rectangle). Its simple issue, no need for video or screenshot. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.4.0-40.44-generic 5.4.44 Uname: Linux 5.4.0-40-generic x86_64 .tmp.unity_support_test.0: ApportVersion: 2.20.11-0ubuntu27.3 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Sun Jul 5 14:18:03 2020 DistUpgraded: Fresh install DistroCodename: focal DistroVariant: ubuntu GraphicsCard: Advanced Micro Devices, Inc. [AMD/ATI] Pitcairn PRO [Radeon HD 7850 / R7 265 / R9 270 1024SP] [1002:6819] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited / Sapphire Technology Radeon HD 7850 2GB GDDR5 DVI-I/DVI-D/HDMI/DP [174b:e221] InstallationDate: Installed on 2020-03-24 (103 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) MachineType: MSI MS-7693 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-40-generic root=UUID=20c309bc-2b22-43b0-938e-0761aa26cd13 ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 10/31/2012 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: V1.11 dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: 970A-G46 (MS-7693) dmi.board.vendor: MSI dmi.board.version: 2.0 dmi.chassis.asset.tag: To Be Filled By O.E.M. dmi.chassis.type: 3 dmi.chassis.vendor: MSI dmi.chassis.version: 2.0 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrV1.11:bd10/31/2012:svnMSI:pnMS-7693:pvr2.0:rvnMSI:rn970A-G46(MS-7693):rvr2.0:cvnMSI:ct3:cvr2.0: dmi.product.family: To be filled by O.E.M. dmi.product.name: MS-7693 dmi.product.sku: To be filled by O.E.M. dmi.product.version: 2.0 dmi.sys.vendor: MSI version.compiz: compiz 1:0.9.14.1+20.04.20200211-0ubuntu1 version.libdrm2: libdrm2 2.4.101-2 version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.8-0ubuntu1~20.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx 20.0.8-0ubuntu1~20.04.1 version.xserver-xorg-core: xserver-xorg-core 2:1.20.8-2ubuntu2.1 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200226-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell-extension-desktop-icons/+bug/1886322/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1883174] Re: Some (or all) desktop icons are missing
I think that the only solution is to uninstall Desktop Icons and install Desktop Icons NG. Although current versions are for Gnome Shell 3.38 and later, there are active versions in extensions.gnome.org that do work with Gnome Shell 3.36. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-desktop-icons in Ubuntu. https://bugs.launchpad.net/bugs/1883174 Title: Some (or all) desktop icons are missing Status in gnome-shell-extension-desktop-icons: Unknown Status in gnome-shell-extension-desktop-icons package in Ubuntu: In Progress Bug description: OS: Ubuntu 20.04 GNOME: 3.36.2 Extension: 3.36.2 Sometimes, some icons in my Desktop folder just don't appear on the desktop. The missing icons aren't invisible, it's like they're not in the folder. Clicking on the empty space where they should be does nothing. Mousing over the empty space does nothing. See attached screenshot. As you can see, there are many missing. Not consistently reproducible, but frequent. This isn't great info, I know. Let me know what else I can provide. To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell-extension-desktop-icons/+bug/1883174/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1883174] Re: Some desktop icons disappear
Can you try this patch? https://gitlab.gnome.org/World/ShellExtensions /desktop-icons/-/merge_requests/184 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-desktop-icons in Ubuntu. https://bugs.launchpad.net/bugs/1883174 Title: Some desktop icons disappear Status in gnome-shell-extension-desktop-icons: Unknown Status in gnome-shell-extension-desktop-icons package in Ubuntu: In Progress Bug description: OS: Ubuntu 20.04 GNOME: 3.36.2 Extension: 3.36.2 Sometimes, some icons in my Desktop folder just don't appear on the desktop. The missing icons aren't invisible, it's like they're not in the folder. Clicking on the empty space where they should be does nothing. Mousing over the empty space does nothing. See attached screenshot. As you can see, there are many missing. Not consistently reproducible, but frequent. This isn't great info, I know. Let me know what else I can provide. To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell-extension-desktop-icons/+bug/1883174/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1883174] Re: Some desktop icons disappear
Good news, then. Also, this means that, maybe, now I can reproduce the bug. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-desktop-icons in Ubuntu. https://bugs.launchpad.net/bugs/1883174 Title: Some desktop icons disappear Status in gnome-shell-extension-desktop-icons: Unknown Status in gnome-shell-extension-desktop-icons package in Ubuntu: In Progress Bug description: OS: Ubuntu 20.04 GNOME: 3.36.2 Extension: 3.36.2 Sometimes, some icons in my Desktop folder just don't appear on the desktop. The missing icons aren't invisible, it's like they're not in the folder. Clicking on the empty space where they should be does nothing. Mousing over the empty space does nothing. See attached screenshot. As you can see, there are many missing. Not consistently reproducible, but frequent. This isn't great info, I know. Let me know what else I can provide. To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell-extension-desktop-icons/+bug/1883174/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1883174] Re: Some desktop icons disappear
AFAIK, if you launch a gnome session, and then you return to the ubuntu session, you shouldn't lost your configuration. So maybe you can do a test in the gnome shell session to check if the patch works, thus allowing canonical to integrate it, but use the ubuntu session for your day-to-day work. Someone here that confirms this? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-desktop-icons in Ubuntu. https://bugs.launchpad.net/bugs/1883174 Title: Some desktop icons disappear Status in gnome-shell-extension-desktop-icons: Unknown Status in gnome-shell-extension-desktop-icons package in Ubuntu: In Progress Bug description: OS: Ubuntu 20.04 GNOME: 3.36.2 Extension: 3.36.2 Sometimes, some icons in my Desktop folder just don't appear on the desktop. The missing icons aren't invisible, it's like they're not in the folder. Clicking on the empty space where they should be does nothing. Mousing over the empty space does nothing. See attached screenshot. As you can see, there are many missing. Not consistently reproducible, but frequent. This isn't great info, I know. Let me know what else I can provide. To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell-extension-desktop-icons/+bug/1883174/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 1883174] Re: Some desktop icons disappear
Yes, I understand. But it seems that the ubuntu session blocks new versions from extensions.gnome.org. AFAIK, they did that to avoid a new version from the repository to overwrite the official, tested one. So it seems that you will need to use the gnome shell session instead. But the other extensions will work in both sessions, at most you will only have to enable them again. El 30/9/20 a las 20:36, John Hoff escribió: > I am not sure I am following. To be clearer, I have multiple other > extensions installed and they all work fine... specifically unite, > walkpaper, user themes and workspace indicator. It is just the desktop > icons one that I can't install or work with. I do already have gnome- > shell-extensions installed... > -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-desktop-icons in Ubuntu. https://bugs.launchpad.net/bugs/1883174 Title: Some desktop icons disappear Status in gnome-shell-extension-desktop-icons: Unknown Status in gnome-shell-extension-desktop-icons package in Ubuntu: In Progress Bug description: OS: Ubuntu 20.04 GNOME: 3.36.2 Extension: 3.36.2 Sometimes, some icons in my Desktop folder just don't appear on the desktop. The missing icons aren't invisible, it's like they're not in the folder. Clicking on the empty space where they should be does nothing. Mousing over the empty space does nothing. See attached screenshot. As you can see, there are many missing. Not consistently reproducible, but frequent. This isn't great info, I know. Let me know what else I can provide. To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell-extension-desktop-icons/+bug/1883174/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 1883174] Re: Some desktop icons disappear
Oh, ok... Now I understand. You simply can't install the official desktop icons in the Ubuntu session. You must install gnome-session, choose gnome shell session instead of Ubuntu session when logging, and there you can use the extensions. Of course, you may want to also install dash-to-dock, that gives you the left dock, and kstatusNotifier. El mié., 30 sept. 2020 20:11, John Hoff <1883...@bugs.launchpad.net> escribió: > I rebooted multiple times and no luck. > > Here are the steps I followed : > > - Used sudo apt remove gnome-shell-extension-desktop-icons to uninstall > > - Deleted the folder $HOME/.local/share/gnome-shell/extensions/desktop- > icons@csoriano > > - Rebooted and verified it is gone all together from tweaks > > - Downloaded the .zip patch file and placed in a local directory > > - Rerean the Meson/Ninja commands and verified that the .local folder > was recreated (I did not get any errors) > > - Rebooted again. > > At this point I still do not have desktop icons as a choice at all in > Tweaks -> extensions. If I go to the website > (https://extensions.gnome.org/) then it is not listed in the installed > extensions list. If I search for it and try to turn it on with the web > page I get a message that says "Can't install "desktop-icons@csoriano" : > This is an extension enabled by your current mode, you can't install > manually any update in that session" > > So basically I am stuck with no option to turn it back on. I suspect I > can just run sudo apt install and readd that way, but it will be the > same /usr install.Am I missing something? > > -- > You received this bug notification because you are a bug assignee. > https://bugs.launchpad.net/bugs/1883174 > > Title: > Some desktop icons disappear > > To manage notifications about this bug go to: > > https://bugs.launchpad.net/gnome-shell-extension-desktop-icons/+bug/1883174/+subscriptions > -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-desktop-icons in Ubuntu. https://bugs.launchpad.net/bugs/1883174 Title: Some desktop icons disappear Status in gnome-shell-extension-desktop-icons: Unknown Status in gnome-shell-extension-desktop-icons package in Ubuntu: In Progress Bug description: OS: Ubuntu 20.04 GNOME: 3.36.2 Extension: 3.36.2 Sometimes, some icons in my Desktop folder just don't appear on the desktop. The missing icons aren't invisible, it's like they're not in the folder. Clicking on the empty space where they should be does nothing. Mousing over the empty space does nothing. See attached screenshot. As you can see, there are many missing. Not consistently reproducible, but frequent. This isn't great info, I know. Let me know what else I can provide. To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell-extension-desktop-icons/+bug/1883174/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 1883174] Re: Some desktop icons disappear
Don't forget to exit and enter again from gnome shell El mié., 30 sept. 2020 17:41, John Hoff <1883...@bugs.launchpad.net> escribió: > Nevermind, I figured out its just sudo apt remove gnome-shell-extension- > desktop-icons. > > I did that and its completely gone from /usr now. However, I no longer > have the extension at all. I reran the steps to install the patch > version and I don't see the extension, so I must be missing a step > somewhere... > > -- > You received this bug notification because you are a bug assignee. > https://bugs.launchpad.net/bugs/1883174 > > Title: > Some desktop icons disappear > > To manage notifications about this bug go to: > > https://bugs.launchpad.net/gnome-shell-extension-desktop-icons/+bug/1883174/+subscriptions > -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-desktop-icons in Ubuntu. https://bugs.launchpad.net/bugs/1883174 Title: Some desktop icons disappear Status in gnome-shell-extension-desktop-icons: Unknown Status in gnome-shell-extension-desktop-icons package in Ubuntu: In Progress Bug description: OS: Ubuntu 20.04 GNOME: 3.36.2 Extension: 3.36.2 Sometimes, some icons in my Desktop folder just don't appear on the desktop. The missing icons aren't invisible, it's like they're not in the folder. Clicking on the empty space where they should be does nothing. Mousing over the empty space does nothing. See attached screenshot. As you can see, there are many missing. Not consistently reproducible, but frequent. This isn't great info, I know. Let me know what else I can provide. To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell-extension-desktop-icons/+bug/1883174/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 1883174] Re: Some desktop icons disappear
The package is "gnome-shell-extension-desktop-icons" El mié., 30 sept. 2020 17:26, John Hoff <1883...@bugs.launchpad.net> escribió: > How do you uninstall it properly? I enabled it through the > https://extensions.gnome.org/ page, but there is not an uninstall option > there. It does not show up as an installed .deb in ubuntu software, so > I am assuming we need to do a sudo apt remove, but not sure what package > is called > > -- > You received this bug notification because you are a bug assignee. > https://bugs.launchpad.net/bugs/1883174 > > Title: > Some desktop icons disappear > > To manage notifications about this bug go to: > > https://bugs.launchpad.net/gnome-shell-extension-desktop-icons/+bug/1883174/+subscriptions > -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-desktop-icons in Ubuntu. https://bugs.launchpad.net/bugs/1883174 Title: Some desktop icons disappear Status in gnome-shell-extension-desktop-icons: Unknown Status in gnome-shell-extension-desktop-icons package in Ubuntu: In Progress Bug description: OS: Ubuntu 20.04 GNOME: 3.36.2 Extension: 3.36.2 Sometimes, some icons in my Desktop folder just don't appear on the desktop. The missing icons aren't invisible, it's like they're not in the folder. Clicking on the empty space where they should be does nothing. Mousing over the empty space does nothing. See attached screenshot. As you can see, there are many missing. Not consistently reproducible, but frequent. This isn't great info, I know. Let me know what else I can provide. To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell-extension-desktop-icons/+bug/1883174/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 1883174] Re: Some desktop icons disappear
That's the problem: the package isn't installed in the local folder, but in /usr. You must uninstall it. El mié., 30 sept. 2020 16:26, John Hoff <1883...@bugs.launchpad.net> escribió: > The editor I am using is just gedit 3.36.2, just fyi... > > -- > You received this bug notification because you are a bug assignee. > https://bugs.launchpad.net/bugs/1883174 > > Title: > Some desktop icons disappear > > To manage notifications about this bug go to: > > https://bugs.launchpad.net/gnome-shell-extension-desktop-icons/+bug/1883174/+subscriptions > -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-desktop-icons in Ubuntu. https://bugs.launchpad.net/bugs/1883174 Title: Some desktop icons disappear Status in gnome-shell-extension-desktop-icons: Unknown Status in gnome-shell-extension-desktop-icons package in Ubuntu: In Progress Bug description: OS: Ubuntu 20.04 GNOME: 3.36.2 Extension: 3.36.2 Sometimes, some icons in my Desktop folder just don't appear on the desktop. The missing icons aren't invisible, it's like they're not in the folder. Clicking on the empty space where they should be does nothing. Mousing over the empty space does nothing. See attached screenshot. As you can see, there are many missing. Not consistently reproducible, but frequent. This isn't great info, I know. Let me know what else I can provide. To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell-extension-desktop-icons/+bug/1883174/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1883174] Re: Some desktop icons disappear
Your guess is correct. The problem is that the line numbers in your log doesn't match my line numbers... Did you uninstall the gnome-shell- extensions-desktop-icons.deb package before installing the branch from gitlab? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-desktop-icons in Ubuntu. https://bugs.launchpad.net/bugs/1883174 Title: Some desktop icons disappear Status in gnome-shell-extension-desktop-icons: Unknown Status in gnome-shell-extension-desktop-icons package in Ubuntu: In Progress Bug description: OS: Ubuntu 20.04 GNOME: 3.36.2 Extension: 3.36.2 Sometimes, some icons in my Desktop folder just don't appear on the desktop. The missing icons aren't invisible, it's like they're not in the folder. Clicking on the empty space where they should be does nothing. Mousing over the empty space does nothing. See attached screenshot. As you can see, there are many missing. Not consistently reproducible, but frequent. This isn't great info, I know. Let me know what else I can provide. To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell-extension-desktop-icons/+bug/1883174/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1883174] Re: Some desktop icons disappear
I tried that, but I'm unable to reproduce that bug. Can you check if there is any error message in the gnome shell logs? (you can see them from a terminal with "sudo journalctl /usr/bin/gnome- shell", and pressing the "END" key to go to the end of the file). -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-desktop-icons in Ubuntu. https://bugs.launchpad.net/bugs/1883174 Title: Some desktop icons disappear Status in gnome-shell-extension-desktop-icons: Unknown Status in gnome-shell-extension-desktop-icons package in Ubuntu: In Progress Bug description: OS: Ubuntu 20.04 GNOME: 3.36.2 Extension: 3.36.2 Sometimes, some icons in my Desktop folder just don't appear on the desktop. The missing icons aren't invisible, it's like they're not in the folder. Clicking on the empty space where they should be does nothing. Mousing over the empty space does nothing. See attached screenshot. As you can see, there are many missing. Not consistently reproducible, but frequent. This isn't great info, I know. Let me know what else I can provide. To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell-extension-desktop-icons/+bug/1883174/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1886322] Re: Unable to move all selected files on desktop
Uploaded a patch. Test and review pending. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-desktop-icons in Ubuntu. https://bugs.launchpad.net/bugs/1886322 Title: Unable to move all selected files on desktop Status in gnome-shell-extension-desktop-icons: Unknown Status in gnome-shell-extension-desktop-icons package in Ubuntu: Confirmed Bug description: Hi, This bug started to happen like 1-2 months ago, and as I remember I didn't do any customizations like installing any external plugins and etc, but I have some stuff already like custom icons, shell, theme... but it worked normaly before. What is happening is that when I select more than 1 file on desktop, no matter which file it is (folder, .txt, image.. anything), and when I try to move around desktop from one place to another, it will move only 1 file and not the rest. So, unable to move selected files on desktop (drag and drop using cursor's rectangle). Its simple issue, no need for video or screenshot. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.4.0-40.44-generic 5.4.44 Uname: Linux 5.4.0-40-generic x86_64 .tmp.unity_support_test.0: ApportVersion: 2.20.11-0ubuntu27.3 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Sun Jul 5 14:18:03 2020 DistUpgraded: Fresh install DistroCodename: focal DistroVariant: ubuntu GraphicsCard: Advanced Micro Devices, Inc. [AMD/ATI] Pitcairn PRO [Radeon HD 7850 / R7 265 / R9 270 1024SP] [1002:6819] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited / Sapphire Technology Radeon HD 7850 2GB GDDR5 DVI-I/DVI-D/HDMI/DP [174b:e221] InstallationDate: Installed on 2020-03-24 (103 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) MachineType: MSI MS-7693 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-40-generic root=UUID=20c309bc-2b22-43b0-938e-0761aa26cd13 ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 10/31/2012 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: V1.11 dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: 970A-G46 (MS-7693) dmi.board.vendor: MSI dmi.board.version: 2.0 dmi.chassis.asset.tag: To Be Filled By O.E.M. dmi.chassis.type: 3 dmi.chassis.vendor: MSI dmi.chassis.version: 2.0 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrV1.11:bd10/31/2012:svnMSI:pnMS-7693:pvr2.0:rvnMSI:rn970A-G46(MS-7693):rvr2.0:cvnMSI:ct3:cvr2.0: dmi.product.family: To be filled by O.E.M. dmi.product.name: MS-7693 dmi.product.sku: To be filled by O.E.M. dmi.product.version: 2.0 dmi.sys.vendor: MSI version.compiz: compiz 1:0.9.14.1+20.04.20200211-0ubuntu1 version.libdrm2: libdrm2 2.4.101-2 version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.8-0ubuntu1~20.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx 20.0.8-0ubuntu1~20.04.1 version.xserver-xorg-core: xserver-xorg-core 2:1.20.8-2ubuntu2.1 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200226-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell-extension-desktop-icons/+bug/1886322/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1883174] Re: Some desktop icons disappear
Can someone test this patch? https://gitlab.gnome.org/World/ShellExtensions/desktop- icons/-/merge_requests/184 It should fix this. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-desktop-icons in Ubuntu. https://bugs.launchpad.net/bugs/1883174 Title: Some desktop icons disappear Status in gnome-shell-extension-desktop-icons: Unknown Status in gnome-shell-extension-desktop-icons package in Ubuntu: Triaged Bug description: OS: Ubuntu 20.04 GNOME: 3.36.2 Extension: 3.36.2 Sometimes, some icons in my Desktop folder just don't appear on the desktop. The missing icons aren't invisible, it's like they're not in the folder. Clicking on the empty space where they should be does nothing. Mousing over the empty space does nothing. See attached screenshot. As you can see, there are many missing. Not consistently reproducible, but frequent. This isn't great info, I know. Let me know what else I can provide. To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell-extension-desktop-icons/+bug/1883174/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1861280] Re: Desktop icons reshuffle themselves
Does this still happen in Ubuntu 20.04? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-desktop-icons in Ubuntu. https://bugs.launchpad.net/bugs/1861280 Title: Desktop icons reshuffle themselves Status in gnome-shell-extension-desktop-icons: Unknown Status in gnome-shell-extension-desktop-icons package in Ubuntu: Confirmed Bug description: It may be a bad habit, but for years I have saved temporary files (stuff I don't intend to keep long & some work in progress) to my desktop, where I won't forget them & they are immediately available. For years there was no problem - icons on the desktop stayed where they were. Since 19.10 things have gone crazy (might have started with 19.04 but I can't check that now). Nearly every time a new item is added or removed, some or all of the other items get reshuffled on the desk! I raised this issue on Ubuntu Forum, with details & screenshots (PLEASE LOOK) here: https://ubuntuforums.org/showthread.php?t=2435768 I have run comparison tests, using SHA-verified Live USB stick versions of Ubuntu 18.04.3 & 19.10, which I suppose anybody else can duplicate. My test was to successively "Save-as to desktop" 32 tiny LibO files called 01, 02, 03 etc in that order. With 18.04.3, each item was positioned top-to-bottom in a column at left, then in the next columns to the right after each column was full. Once positioned, no icon moved. With 19.10, icons were positioned clustered top-left but new columns were started before previous columns were full. Nearly every addition caused previous icons to be reshuffled. Frequently the number of columns DIMINISHED when a new icon was added. With 19.10, removing icons causes other items to reshuffle. With 18.04.3, removing icons leaves a gap, which is filled by the next item added. I think the behaviour of 18.04.3 is perfect & the behaviour of 19.10 is an unacceptable regression. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: nautilus 1:3.34.1-1ubuntu1 ProcVersionSignature: Ubuntu 5.3.0-29.31-generic 5.3.13 Uname: Linux 5.3.0-29-generic x86_64 ApportVersion: 2.20.11-0ubuntu8.2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Wed Jan 29 14:03:30 2020 InstallationDate: Installed on 2014-10-23 (1923 days ago) InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) SourcePackage: nautilus UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.default.apport: # set this to 0 to disable apport, or to 1 to enable it # you can temporarily override this with # sudo service apport start force_start=1 enabled=0 mtime.conffile..etc.default.apport: 2019-11-04T18:03:11.954726 usr_lib_nautilus: To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell-extension-desktop-icons/+bug/1861280/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1844808] Re: Can't delete file from desktop by clicking it and hitting delete key
I'm the developer of Desktop Icons. Yes, I'm working on it, but any help is appreciated ;-) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-desktop-icons in Ubuntu. https://bugs.launchpad.net/bugs/1844808 Title: Can't delete file from desktop by clicking it and hitting delete key Status in gnome-shell-extension-desktop-icons: Unknown Status in gnome-shell-extension-desktop-icons package in Ubuntu: Triaged Bug description: Just upgraded to 19.10 today. Previously, in 19.04, I could delete a file from the desktop by clicking on it and hitting the delete key. That no longer works. It's probably relevant that it doesn't appear to be possible to direct keyboard focus to the desktop itself any longer. When I click on an icon on the desktop and then hit the delete key, the keystroke is sent to the window that had focus before I clicked. This appears to be true regardless of what window focus mode I'm using (Click to Focus, Focus on Hover, or Secondary-Click). Note that the description of Secondary- Click, "Window is focused when hovered with the pointer. Hovering the desktop removes focus from the previous window," does not appear to be true. When I select that focus mode and hover my mouse over the desktop I remain focused on the previously focused window. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: gnome-shell-extension-desktop-icons 19.01.4-1 ProcVersionSignature: Ubuntu 5.3.0-10.11-generic 5.3.0-rc8 Uname: Linux 5.3.0-10-generic x86_64 ApportVersion: 2.20.11-0ubuntu7 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Sep 20 11:12:42 2019 InstallationDate: Installed on 2019-09-12 (7 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) PackageArchitecture: all SourcePackage: gnome-shell-extension-desktop-icons UpgradeStatus: Upgraded to eoan on 2019-09-20 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell-extension-desktop-icons/+bug/1844808/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1868529] Re: Stretched image previews on desktop
Sorry, the patch is at https://gitlab.gnome.org/World/ShellExtensions /desktop-icons/-/merge_requests/166 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-desktop-icons in Ubuntu. https://bugs.launchpad.net/bugs/1868529 Title: Stretched image previews on desktop Status in gnome-shell-extension-desktop-icons: Unknown Status in gnome-shell-extension-desktop-icons package in Ubuntu: Triaged Bug description: After upgrade to 20.04 desktop previews of pictures and documents became stretched. The regular previews in Nautilus have normal sizes. See attached pic ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: gnome-shell-extension-desktop-icons 19.10.2+git20200223-1 ProcVersionSignature: Ubuntu 5.4.0-18.22-generic 5.4.24 Uname: Linux 5.4.0-18-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia wl ApportVersion: 2.20.11-0ubuntu21 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Mar 23 11:44:13 2020 PackageArchitecture: all ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=ru_RU.UTF-8 SHELL=/bin/bash SourcePackage: gnome-shell-extension-desktop-icons UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell-extension-desktop-icons/+bug/1868529/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1868529] Re: Stretched image previews on desktop
I'm the developer of desktop icons. I have a patch waiting review that should fix this at https://gitlab.gnome.org/World/ShellExtensions /desktop-icons/-/issues/190 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-desktop-icons in Ubuntu. https://bugs.launchpad.net/bugs/1868529 Title: Stretched image previews on desktop Status in gnome-shell-extension-desktop-icons: Unknown Status in gnome-shell-extension-desktop-icons package in Ubuntu: Triaged Bug description: After upgrade to 20.04 desktop previews of pictures and documents became stretched. The regular previews in Nautilus have normal sizes. See attached pic ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: gnome-shell-extension-desktop-icons 19.10.2+git20200223-1 ProcVersionSignature: Ubuntu 5.4.0-18.22-generic 5.4.24 Uname: Linux 5.4.0-18-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia wl ApportVersion: 2.20.11-0ubuntu21 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Mar 23 11:44:13 2020 PackageArchitecture: all ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=ru_RU.UTF-8 SHELL=/bin/bash SourcePackage: gnome-shell-extension-desktop-icons UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell-extension-desktop-icons/+bug/1868529/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1846776] Re: Renaming a desktop item causes the shell to hang
I did several tries yesterday, but none of them worked. First I tried to remove the "emit" calls and the "addSignalMethods" in desktopGrid, just in case the problem was an incompatibility with the new class system in Gnome Shell 3.34. Also removed all the grabHelper calls, but also didn't work. The problem seems to be the text entry, that is not editable. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-desktop-icons in Ubuntu. https://bugs.launchpad.net/bugs/1846776 Title: Renaming a desktop item causes the shell to hang Status in gnome-shell-extension-desktop-icons: New Status in gnome-shell-extension-desktop-icons package in Ubuntu: In Progress Bug description: Right click on a desktop icon and rename it: - The shell will hang and there's no way to recover it To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell-extension-desktop-icons/+bug/1846776/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1705459] Re: Cannot switch to another workspace when an sqlitebrowser window is open
There is a fix published in the main thread at github https://github.com/kehugter/sqlitebrowser/commit/c4c4cf62a2adf90c7604a920c409c27192f177ce -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell in Ubuntu. https://bugs.launchpad.net/bugs/1705459 Title: Cannot switch to another workspace when an sqlitebrowser window is open Status in gnome-shell package in Ubuntu: New Bug description: Test Case Pre-requisites: - Several workspaces must be open - Install sqlitebrowser 1. Launch sqlitebrowser 2. Switch to another workspace user the workspace switcher, switching to an app on another workspace or a short-cut 3. Minimize the sqlitebrowser window Expected result User can switch to another workspace or minimize the window Actual result The shells switches back to previous state (stays on same workspace or remaximize the window) ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: gnome-shell 3.24.2-0ubuntu7 ProcVersionSignature: Ubuntu 4.10.0-26.30-generic 4.10.17 Uname: Linux 4.10.0-26-generic x86_64 ApportVersion: 2.20.5-0ubuntu5 Architecture: amd64 CurrentDesktop: GNOME Date: Thu Jul 20 13:37:34 2017 DisplayManager: gdm3 InstallationDate: Installed on 2014-07-15 (1101 days ago) InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Alpha amd64 (20140520) SourcePackage: gnome-shell UpgradeStatus: Upgraded to artful on 2015-12-08 (589 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1705459/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1181106] Re: Failed to change profile to A2DP in 13.04 (Raring), 13.10 (saucy), and 14.04 (trusty)
Hi all: I have exactly the same problem as everyone, and tried everything commented here without success. But I found a way of doing it work, which maybe helps to fix the error: * Paired my headset, but didn't set it as trusted. Restarted the bluetooth service (did this only once, not every time I want to connect your headset; is just to set it in a know state). * Now, every time I want to use the headset, I turn it on. Bluetooth icon in gnome will briefly show as connected, but returns to disconnected (because it detected the paired device, but, as it is not a trusted one, will no connect automatically to it). * Wait about ten seconds until I hear a little "pop" in my headset (I suspect it is when, after waiting a connection, it puts in some kind of sleep mode to save battery) * Now I can go to the bluetooth icon and set A2DP mode, and everything works fine. If I try to connect it before that status change, the headset will stuck in HSP/HFP mode and will refuse to change to A2DP mode. But there is a case when this fails: sometimes, when turning on the headset, Gnome shell shows a popup and asks me if I want to accept the connection. In that case, no matter if I accept or deny it, waiting to hear the "pop" doesn't work: it will also remain stuck in HSP/HFP mode. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1181106 Title: Failed to change profile to A2DP in 13.04 (Raring), 13.10 (saucy), and 14.04 (trusty) Status in Bluez Utilities: New Status in pulseaudio package in Ubuntu: Confirmed Status in pulseaudio package in Debian: Fix Released Bug description: I upgraded to 13.04 recently and my A2DP profile, which had been working great under 12.10 is suddenly gone. Neither my blueman applet nor the built-in bluetooth manager applet can connect my external bluetooth speaker to the A2DP profile. They can connect to the bluetooth device itself just fine. Steps I'm using: * using blueman, I can connect to the external bluetooth speaker and view the device in the devices listing * I can connect the device to the Audio sink and I get a message saying it is now connected and will "show in the PulseAudio mixer" * After connecting the external speaker to the audio sink, I can also see the device in the "Play sound through" listing in the Sound system control panel, but the icon has a circle with a line through it. * but if I right-click the device and choose "Audio Profile" from the context menu and try to select "High Fidelity Playback (A2DP)" as the new profile, I get an error message stating "failed to change profile to a2dp" I've already added "Enable=Socket" in /etc/bluetooth/audio.conf, without that I can't pair my headset. Now I can pair it, but I can't activate the A2DP profile. When I try to activate it, I see this message in my syslog : pulseaudio[2603]: [pulseaudio] module-bluetooth-device.c: Profile has no transport I tried the kernel 3.9.0 because of a sound problem with my soundcard, this kernel fixed my soundcard problem, but A2DP still doesn't work To manage notifications about this bug go to: https://bugs.launchpad.net/bluez/+bug/1181106/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
