** No longer affects: chromium-browser (Ubuntu Xenial)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1851250
Title:
[snap] chromium-browser snap cannot upload files outside ~
To manage
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: chromium-browser (Ubuntu Xenial)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: chromium-browser (Ubuntu Focal)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: chromium-browser (Ubuntu Bionic)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Speaking from a desktop perspective those changes seem safe enough if
you confirmed they are resolving the chromium issue? There as some more
fixes in newer version like https://github.com/flatpak/xdg-desktop-
portal/commit/48a981ee but unsure if that's required.
Note that usually we would
Here are the changes we'd need to backport to Focal in order to fix this
bug there:
To package xdg-desktop-portal-gtk:
-
https://github.com/flatpak/xdg-desktop-portal-gtk/commit/920afdde7afc023e77ecfeb4e174cb42f22cbfe3
To package xdg-desktop-portal:
-
Hi Olivier, let me take some time to investigate what are the changes to
the next major version, because if we are lucky and they are small and
safe, we could really think about a SRU. At least for 20.04, which is
going to be supported for quite a few years from now.
Also, let's keep in mind that
Thanks for testing, and for the feedback Alberto.
Let's say it's okay to assume that the portal is already running and accessible
through the bus (i.e. the ListActivatableNames path won't be taken − there's an
upstream bug to track this:
Hi Olivier! I tried on hirsute, and it's working :-)
Then I guess that the only series still supported by Canonical and
affected by this bug are the LTSes.
** Also affects: chromium-browser (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: chromium-browser (Ubuntu
I'm reopening this bug in light of Alberto's recent findings.
Alberto, it would be useful if you could test this on a more recent
system, e.g. impish, and report whether with a new enough version of the
portal, opening/saving files anywhere on the filesystem works.
** Changed in:
After some good hints from Oliver I did some investigation on this
issue. Indeed it looks like the chromium snap is doing the right thing:
it first checks if the D-Bus service "org.freedesktop.portal.Desktop" is
running (if not, it falls back on calling ListActivatableNames, which is
not ideal
Hi Olivier (or whoever knows about Chromium), I see that the upstream
support for the XDG file selector portal landed somewhere in July this
year (https://chromium-
review.googlesource.com/c/chromium/src/+/2992214/), but I cannot find
information on which Chromium version contains this change.
Here I am, trying to use headless Chromium to render screenshots, and on
Ubuntu 20.04, I find that Chromium is simply not writing to `/tmp`. So,
let me add my voice to the chorus of those flummoxed and frustrated by
this decision.
The easiest way to get around this appears to be to install
As lame as such comments may appear:
The level of suffering on my side is large enough to add that I too am
really irritated by this “feature”. It is a significant obstacle in my
daily workflow, and any workaround must not be necessary in the first
place. We’ve been living with browsers with
This affects me too after upgrading from 18.04 LTS to 20.04 and I fint
it COMPLETELY UNACCEPTABLE.
The use of symlinks from /home to data on larger drives (which are shared
between windows and linux systems, and not unix FS) is industry standard since
over 30 years and this regression is
I'm noting that nearly a year after this has been reported there is still no
fix and no workaround.
It may be marked as *invalid* because it is a *feature* but there is no way to
turn that feature off and get my work done.
Please reopen and put a control to disable this mal-feature on the
I'm not familiar with Veracrypt, but according to their documentation¹,
it is possible to mount encrypted volumes as removable drives, which
presumably would be mounted under /mnt or /media, and those can be
accessed using the removable-media interface².
¹
Those who use Veracrypt or similar mounted drives - good luck trying to
access those files from Chromium!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1851250
Title:
[snap] chromium-browser snap
> I can't download files into /tmp so I don't have delete them later
/tmp in the chromium snap is mapped to /tmp/snap.chromium/tmp, so files
downloaded there won't be persistent across reboots.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
At least in Firefox you can use Ctrl + L to access a location
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1851250
Title:
[snap] chromium-browser snap cannot upload files outside ~
To manage
I'm afraid I do have to add my voice to this particular complaint as
most packages I install with snap seem to have fundamental problems
accessing the file system however it's configured with multiple mount
points, sim links etc. I've already removed many snap apps and
reinstalled with apt which
Ah finally figure out the source of this brokenness
I'm also suffering from this - for 15+ years now my home directory has
largely consisted of symbolic links to directories in other mounted file
systems (not mounted under /mnt)
I can't upload PCB gerber files to get PCBs made, I can't
As annoying as it may seem, this is a feature of the snap confinement,
for improved security (the app isn't allowed to see files on the host
system, except for non-hidden files and folders under $HOME and /mnt and
/media (if the removable-media interface is connected).
This will be addressed in
Also I cannot _download_ files. In the dpkg installation, they were
saved to /tmp and could be opened with the appropriate helper program
(e.g., Evince). Now I see the download in the bottom of the browser bar,
but the file will not open (clicks are ignored). chrome://downloads/
displays them, but
24 matches
Mail list logo
