[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 1971168] Re: [snap] Files on local network shares are not opened / written
Sergio any news about this? -- 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 1971168] Re: [snap] Files on local network shares are not opened / written
Ubuntu 23.04 (Lunar Lobster) has reached end of life, so this bug will not be fixed for that specific release. ** Changed in: xdg-desktop-portal-gnome (Ubuntu Lunar) Status: Triaged => Won't Fix -- 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 1971168] Re: [snap] Files on local network shares are not opened / written
** Changed in: firefox Status: Confirmed => Fix Released -- 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] Re: [snap] Files on local network shares are not opened / written
Ok Thks for all the work -- 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
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 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 1971168] Re: [snap] Files on local network shares are not opened / written
Soo no fix to 22.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 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
It don't work, you can select a file but it don´t upload ** Attachment added: "Captura de ecrã de 2024-01-05 12-32-13.png" https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1971168/+attachment/5736847/+files/Captura%20de%20ecr%C3%A3%20de%202024-01-05%2012-32-13.png -- 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] Re: [snap] Files on local network shares are not opened / written
Hi, This bug going to be solved for 22.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 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 + 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 / Chromium + 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: 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
[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] Re: [snap] Files on local network shares are not opened / written
** Patch added: "filechooser_42.1_patch.diff" https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1971168/+attachment/5705189/+files/filechooser_42.1_patch.diff -- 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 attachment "filechooser_42.1_patch.diff" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team. [This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.] ** Tags added: 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 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
For those who are interested. I modified the patch from Sergio Costas Rodriguez to version 42.1 which is shipped with Ubuntu 22.04 It works on my laptop :-) ** Patch added: "filechooser_42.1_patch.diff" https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1971168/+attachment/5705190/+files/filechooser_42.1_patch.diff ** Patch removed: "filechooser_42.1_patch.diff" https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1971168/+attachment/5705189/+files/filechooser_42.1_patch.diff -- 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
Can someone please explain how this is now logged as fix released when the upstream MR https://gitlab.gnome.org/GNOME/xdg-desktop-portal- gnome/-/merge_requests/67 is still open? In other words, is this an Ubuntu-only 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 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
This bug was fixed in the package xdg-desktop-portal-gnome - 44.1-2 --- xdg-desktop-portal-gnome (44.1-2) experimental; urgency=medium * Add patch to send remote file URIs as local FUSE URIs (LP: #1971168) -- Sergio Costas Rodriguez Tue, 18 Jul 2023 10:35:30 -0400 ** Changed in: xdg-desktop-portal-gnome (Ubuntu) Status: Fix Committed => Fix Released -- 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
** 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] Re: [snap] Files on local network shares are not opened / written
** Also affects: firefox (Ubuntu Lunar) Importance: Undecided Status: New ** Also affects: xdg-desktop-portal (Ubuntu Lunar) Importance: Undecided Status: New ** Also affects: xdg-desktop-portal-gnome (Ubuntu Lunar) Importance: Undecided Status: New ** Also affects: firefox (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: xdg-desktop-portal (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: xdg-desktop-portal-gnome (Ubuntu Jammy) Importance: Undecided Status: New ** No longer affects: xdg-desktop-portal (Ubuntu Jammy) ** No longer affects: xdg-desktop-portal (Ubuntu Lunar) ** No longer affects: firefox (Ubuntu Jammy) ** No longer affects: firefox (Ubuntu Lunar) ** Changed in: xdg-desktop-portal-gnome (Ubuntu Jammy) Status: New => Triaged ** Changed in: xdg-desktop-portal-gnome (Ubuntu Lunar) Status: New => Triaged ** Changed in: xdg-desktop-portal-gnome (Ubuntu) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xdg-desktop-portal-gnome 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 Committed Status in xdg-desktop-portal-gnome source package in Jammy: Triaged Status in xdg-desktop-portal-gnome source package in Lunar: 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] Re: [snap] Files on local network shares are not opened / written
** Also affects: xdg-desktop-portal-gnome (Ubuntu) Importance: Undecided Status: New ** Changed in: xdg-desktop-portal-gnome (Ubuntu) Status: New => In Progress ** Changed in: xdg-desktop-portal-gnome (Ubuntu) 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-gnome 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: In Progress 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] Re: [snap] Files on local network shares are not opened / written
I use Firefox 103 install from source file tar.bz2 extract to /opt/ can save file in partition mount. If use firefox from snap or apt-get repo can't save file in partition mount -- 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] Re: [snap] Files on local network shares are not opened / written
** Changed in: firefox (Ubuntu) Status: Confirmed => Triaged ** Package changed: snapd (Ubuntu) => xdg-desktop-portal (Ubuntu) ** Changed in: xdg-desktop-portal (Ubuntu) Importance: Undecided => High ** Changed in: xdg-desktop-portal (Ubuntu) Status: Confirmed => Triaged -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1971168 Title: [snap] Files on local network shares are not opened / written Status in Mozilla Firefox: Unknown 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] Re: [snap] Files on local network shares are not opened / written
** Changed in: firefox (Ubuntu) Importance: Undecided => High -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1971168 Title: [snap] Files on local network shares are not opened / written Status in Mozilla Firefox: Unknown Status in firefox package in Ubuntu: Confirmed Status in snapd package in Ubuntu: Confirmed 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] Re: [snap] Files on local network shares are not opened / written
New bug ticket was opened where investigation is continued. ** Bug watch added: Mozilla Bugzilla #1773624 https://bugzilla.mozilla.org/show_bug.cgi?id=1773624 ** Changed in: firefox Status: Confirmed => Unknown ** Changed in: firefox Remote watch: Mozilla Bugzilla #1767316 => Mozilla Bugzilla #1773624 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1971168 Title: [snap] Files on local network shares are not opened / written Status in Mozilla Firefox: Unknown Status in firefox package in Ubuntu: Confirmed Status in snapd package in Ubuntu: Confirmed 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] Re: [snap] Files on local network shares are not opened / written
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: snapd (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox 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: Confirmed Status in snapd package in Ubuntu: Confirmed 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] Re: [snap] Files on local network shares are not opened / written
** Bug watch added: Mozilla Bugzilla #1768500 https://bugzilla.mozilla.org/show_bug.cgi?id=1768500 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox 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: Confirmed Status in snapd package in Ubuntu: New 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
