User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:94.0) Gecko/20100101 Firefox/94.0

Steps to reproduce:

I use Ubuntu, I had Firefox installed as a .deb and I upgraded my Ubuntu version which now uses Firefox as a snap (which you created it seems).

Actual results:

I kept my .mozilla, Documents and Pictures folders on another drive + mount point and had symbolic links to them from my home:

/home/XXXX/.mozilla -> /data/home/XXXX/.mozilla
/home/XXXX/Pictures -> /data/home/XXXX/Pictures
/home/XXXX/Documents -> /data/home/XXXX/Documents

When I first launched Firefox it created a new empty/default profile. I read that on the first launch it should have imported my ~/.mozilla, which it clearly hadn't. I dug around and found that when I run it by command line it complained that it couldn't find the Documents and Pictures folder, so I had a hunch that it was the symbolic links that caused issues. I tried to remove the .mozilla symbolic link and copy the real folder to my /home/XXXX and then ran firefox again (command line) and it worked, I saw that it imported it.

Expected results:

I would expect it be able to work/import from a symbolic link. I also want to know why it can't directly use my folders/symbolic link? Is it going to try to copy my Documents and Pictures folders somewhere else like it did my .mozilla?
Thank you

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

I fear this might be a non-mozilla issue if it is import that is failing. The import code lives at https://code.launchpad.net/~mozilla-snaps/+git/firefox-snap/+ref/profile-import, and I can't see anything reported on https://bugs.launchpad.net/~mozilla-snaps either.

Olivier, should this be treated upstream directly?

Alexandre, even if the profile importer isn't yet upstream code (see bug 1730530), we've been tracking all snap-related bugs here on bugzilla.

Gabriel, indeed the snap's strict confinement policy means that symlinks in the user's home directory to some place outside it are not going to be resolved, unless they point to some place that the confinement explicitly allows, for instance anywhere under /mnt, /media or /run/media. Changing the mount point of your external drive to one of those places should work around the issue. Alternatively, you could bind-mount your .mozilla folder instead of using a symlink, that should work too.
I understand this is not a perfect solution, as it requires some adjustments to your setup that was working seamlessly so far, but with the strict confinement policy I'm not sure what else to suggest.

Note that only the profiles under ~/.mozilla are going to be imported, no other folder will be copied from your home directory to ~/snap/firefox.

(In reply to Olivier Tilloy from comment #3)

Alexandre, even if the profile importer isn't yet upstream code (see bug 1730530), we've been tracking all snap-related bugs here on bugzilla.

Thanks, I was not aware.

Gabriel, indeed the snap's strict confinement policy means that symlinks in the user's home directory to some place outside it are not going to be resolved, unless they point to some place that the confinement explicitly allows, for instance anywhere under /mnt, /media or /run/media. Changing the mount point of your external drive to one of those places should work around the issue. Alternatively, you could bind-mount your .mozilla folder instead of using a symlink, that should work too.
I understand this is not a perfect solution, as it requires some adjustments to your setup that was working seamlessly so far, but with the strict confinement policy I'm not sure what else to suggest.

Note that only the profiles under ~/.mozilla are going to be imported, no other folder will be copied from your home directory to ~/snap/firefox.

Maybe the importer should detect that and fail gently ?

Maybe the importer should detect that and fail gently ?

All the importer will know is that it wasn't allowed to read ~/.mozilla. It won't know whether it's because the folder doesn't exist, because it is a symlink pointing to some place the snap isn't allowed to read, or some other reason.

Do you still reproduce ? Unfortunately if the path is not accessible by Snap, it's going to be blocked as olivier mentionned.

Redirect a needinfo that is pending on an inactive user to the triage owner.
:gerard-majax, since the bug has recent activity, could you please find another way to get the information or close the bug as INCOMPLETE if it is not actionable?

For more information, please visit BugBot documentation.

(In reply to :gerard-majax from comment #6)

Do you still reproduce ? Unfortunately if the path is not accessible by Snap, it's going to be blocked as olivier mentionned.

Hi,

The path was accessible. At least it was by my user (all of /data is accessible by my user)

I have to see if this still happens, but unfortunately my Firefox installation is a bit weird right now, I had switched back to the apt version (due to this issue), then it was removed so I installed the snap again (and uninstalled the apt version) and somehow it sometimes upgrades it and sometimes downgrades it. I haven't had time to investigate much, but I lost my session when this happened (and all my bookmarks and open tabs), which was a bummer. I will try to see what is going on and try to reproduce this issue.

Thanks,
Gabriel

(In reply to Gabriel from comment #8)

(In reply to :gerard-majax from comment #6)

Do you still reproduce ? Unfortunately if the path is not accessible by Snap, it's going to be blocked as olivier mentionned.

Hi,

The path was accessible. At least it was by my user (all of /data is accessible by my user)

But snapd might limit access anyway. Which would be the case for /data. And best I know it's complicated to grant access without changing snapd ...

I have to see if this still happens, but unfortunately my Firefox installation is a bit weird right now, I had switched back to the apt version (due to this issue), then it was removed so I installed the snap again (and uninstalled the apt version) and somehow it sometimes upgrades it and sometimes downgrades it. I haven't had time to investigate much, but I lost my session when this happened (and all my bookmarks and open tabs), which was a bummer. I will try to see what is going on and try to reproduce this issue.

That's another problem. Can you file a new bug in the same component with proper infos to reproduce as well as listing content of ~/snap/firefox?

Thanks,
Gabriel

The severity field is not set for this bug.
:gerard-majax, could you have a look please?

For more information, please visit BugBot documentation.

Nathan, do you have an idea of what we may be able to do on that problem?

Indeed, /data won't work under snap ­— or pretty much anything out of the expected file hierarchy standard. I'm sure Snapd will not budge from that position (exisiting discussions should already exist in forum.snapcraft.io or https://launchpad.net/ubuntu/+source/snapd/+bugs).

If you mount to /media or /mnt instead of /data it will work. Is that a viable alternative for you?