| 2022-05-02 15:26:02 |
Markus W |
bug |
|
|
added bug |
| 2022-05-02 15:34:24 |
Markus W |
description |
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
Additional information:
* When saving to a folder on the local machine instead, saving works correctly as expected. |
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
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 |
|
| 2022-05-02 16:57:14 |
Erich Eickmeyer |
firefox (Ubuntu): status |
New |
Invalid |
|
| 2022-05-05 13:44:11 |
Erich Eickmeyer |
firefox (Ubuntu): status |
Invalid |
Incomplete |
|
| 2022-05-05 13:52:57 |
Markus W |
bug watch added |
|
https://bugzilla.mozilla.org/show_bug.cgi?id=1767316 |
|
| 2022-05-05 14:00:51 |
Olivier Tilloy |
bug task added |
|
firefox |
|
| 2022-05-05 14:00:57 |
Olivier Tilloy |
firefox (Ubuntu): status |
Incomplete |
Confirmed |
|
| 2022-05-05 14:28:13 |
Bug Watch Updater |
firefox: status |
Unknown |
Confirmed |
|
| 2022-05-09 12:27:13 |
Markus W |
bug task added |
|
snapd (Ubuntu) |
|
| 2022-05-09 12:31:32 |
Markus W |
description |
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
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 |
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. |
|
| 2022-05-09 12:32:25 |
Markus W |
summary |
[snap] Downloaded files not saved when saving to local network share |
[snap] Files on local network shares are not opened / written |
|
| 2022-05-10 05:48:51 |
Ikuya Awashiro |
bug |
|
|
added subscriber Ikuya Awashiro |
| 2022-05-15 22:09:28 |
Bug Watch Updater |
bug watch added |
|
https://bugzilla.mozilla.org/show_bug.cgi?id=1768500 |
|
| 2022-05-17 14:56:20 |
Launchpad Janitor |
snapd (Ubuntu): status |
New |
Confirmed |
|
| 2022-06-11 09:48:37 |
Markus W |
bug watch added |
|
https://bugzilla.mozilla.org/show_bug.cgi?id=1773624 |
|
| 2022-06-11 09:48:37 |
Markus W |
firefox: status |
Confirmed |
Unknown |
|
| 2022-06-11 09:48:37 |
Markus W |
firefox: remote watch |
Mozilla Bugzilla #1767316 |
Mozilla Bugzilla #1773624 |
|
| 2022-06-14 10:31:39 |
Sebastien Bacher |
firefox (Ubuntu): importance |
Undecided |
High |
|
| 2022-06-14 10:44:44 |
Sebastien Bacher |
firefox (Ubuntu): status |
Confirmed |
Triaged |
|
| 2022-06-14 10:44:50 |
Sebastien Bacher |
affects |
snapd (Ubuntu) |
xdg-desktop-portal (Ubuntu) |
|
| 2022-06-14 10:44:55 |
Sebastien Bacher |
xdg-desktop-portal (Ubuntu): importance |
Undecided |
High |
|
| 2022-06-14 10:44:58 |
Sebastien Bacher |
xdg-desktop-portal (Ubuntu): status |
Confirmed |
Triaged |
|
| 2022-06-21 15:27:06 |
Bug Watch Updater |
firefox: status |
Unknown |
Confirmed |
|
| 2022-06-21 15:27:10 |
Bug Watch Updater |
bug watch added |
|
https://github.com/flatpak/xdg-desktop-portal/issues/213 |
|
| 2022-06-21 15:27:10 |
Bug Watch Updater |
bug watch added |
|
https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/48 |
|
| 2022-11-05 21:32:09 |
Miguel |
bug |
|
|
added subscriber Miguel |
| 2023-07-17 08:02:36 |
Daniel van Vugt |
bug task added |
|
xdg-desktop-portal-gnome (Ubuntu) |
|
| 2023-07-17 08:02:41 |
Daniel van Vugt |
xdg-desktop-portal-gnome (Ubuntu): status |
New |
In Progress |
|
| 2023-07-17 08:02:51 |
Daniel van Vugt |
xdg-desktop-portal-gnome (Ubuntu): assignee |
|
Sergio Costas (rastersoft-gmail) |
|
| 2023-07-18 14:38:50 |
Jeremy Bícha |
nominated for series |
|
Ubuntu Lunar |
|
| 2023-07-18 14:38:50 |
Jeremy Bícha |
bug task added |
|
firefox (Ubuntu Lunar) |
|
| 2023-07-18 14:38:50 |
Jeremy Bícha |
bug task added |
|
xdg-desktop-portal (Ubuntu Lunar) |
|
| 2023-07-18 14:38:50 |
Jeremy Bícha |
bug task added |
|
xdg-desktop-portal-gnome (Ubuntu Lunar) |
|
| 2023-07-18 14:38:50 |
Jeremy Bícha |
nominated for series |
|
Ubuntu Jammy |
|
| 2023-07-18 14:38:50 |
Jeremy Bícha |
bug task added |
|
firefox (Ubuntu Jammy) |
|
| 2023-07-18 14:38:50 |
Jeremy Bícha |
bug task added |
|
xdg-desktop-portal (Ubuntu Jammy) |
|
| 2023-07-18 14:38:50 |
Jeremy Bícha |
bug task added |
|
xdg-desktop-portal-gnome (Ubuntu Jammy) |
|
| 2023-07-18 14:39:01 |
Jeremy Bícha |
bug task deleted |
xdg-desktop-portal (Ubuntu Jammy) |
|
|
| 2023-07-18 14:39:07 |
Jeremy Bícha |
bug task deleted |
xdg-desktop-portal (Ubuntu Lunar) |
|
|
| 2023-07-18 14:39:11 |
Jeremy Bícha |
bug task deleted |
firefox (Ubuntu Jammy) |
|
|
| 2023-07-18 14:39:17 |
Jeremy Bícha |
bug task deleted |
firefox (Ubuntu Lunar) |
|
|
| 2023-07-18 14:39:21 |
Jeremy Bícha |
xdg-desktop-portal-gnome (Ubuntu Jammy): status |
New |
Triaged |
|
| 2023-07-18 14:39:24 |
Jeremy Bícha |
xdg-desktop-portal-gnome (Ubuntu Lunar): status |
New |
Triaged |
|
| 2023-07-18 14:39:34 |
Jeremy Bícha |
xdg-desktop-portal-gnome (Ubuntu): status |
In Progress |
Fix Committed |
|
| 2023-07-18 14:41:26 |
Jeremy Bícha |
bug |
|
|
added subscriber Jeremy Bícha |
| 2023-07-18 15:03:23 |
Sergio Costas |
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. |
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. |
|
| 2023-07-18 15:03:40 |
Sergio Costas |
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. |
[ 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. |
|
| 2023-07-19 01:01:46 |
Launchpad Janitor |
xdg-desktop-portal-gnome (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2023-08-03 04:05:58 |
Chris Guiver |
bug |
|
|
added subscriber Chris Guiver |
| 2023-09-28 21:05:05 |
Bas van den Heuvel |
attachment added |
|
filechooser_42.1_patch.diff https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1971168/+attachment/5705189/+files/filechooser_42.1_patch.diff |
|
| 2023-09-28 21:08:07 |
Bas van den Heuvel |
attachment added |
|
filechooser_42.1_patch.diff https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1971168/+attachment/5705190/+files/filechooser_42.1_patch.diff |
|
| 2023-09-28 21:59:15 |
Bas van den Heuvel |
attachment removed |
filechooser_42.1_patch.diff https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1971168/+attachment/5705189/+files/filechooser_42.1_patch.diff |
|
|
| 2023-09-29 00:19:12 |
Ubuntu Foundations Team Bug Bot |
tags |
snap |
patch snap |
|
| 2023-09-29 00:19:16 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Review Team |
| 2024-05-22 22:04:57 |
Bug Watch Updater |
firefox: status |
Confirmed |
Fix Released |
|
