1467094 - Import from the Chromium Snap profile doesn't work (Firefox can't detect Chromium being installed)

Status: VERIFIED FIXED

(Firefox :: Migration, defect, P2)

Description

[Jamba]

Attachment: Screenshot from 2018-06-06 15-19-51.png

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180517114003

Steps to reproduce:

I've tried tried import bookmarks from Chromium browser on Ubuntu 18.04


Actual results:

Firefox can't detect Chromium browser


Expected results:

Chromium browser detection

Comment 1

[Matthew N. [:MattN]]

Hello, we are supposed to support Chromium imports on Linux but it's possible Ubuntu installs it in a different place.[1]

Can you open chrome://version/ while in Chromium and share the "Profile Path" directory?

[1] https://dxr.mozilla.org/mozilla-central/rev/cec4a3cecc29ff97860198969b6fdff24b9e93bb/browser/components/migration/ChromeMigrationUtils.jsm#221,238-239

Comment 2

[Sam Foster [:sfoster] (he/him)]

On Ubuntu 16.04 my profile path for Chromium is: /home/sfoster/.config/chromium/Default
Import of Chromium bookmarks into a new nightly profile worked for me. It would seem odd (though I guess possible) that the profile paths would change in 18.04?

Comment 3

[Jamba]

Here is output

Chromium	67.0.3396.62 (Official Build) (64-bit)
Revision	babbbb5b433370f9a7feeb9f98a57599ad1c4676-refs/branch-heads/3396@{#702}
OS	Linux
JavaScript	V8 6.7.288.42
Flash	(Disabled)
User Agent	Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/67.0.3396.62 Chrome/67.0.3396.62 Safari/537.36
Command Line	/snap/chromium/353/usr/lib/chromium-browser/chromium-browser --no-default-browser-check --no-first-run --password-store=basic --ppapi-flash-path --flag-switches-begin --flag-switches-end
Executable Path	/snap/chromium/353/usr/lib/chromium-browser/chromium-browser
Profile Path	/home/ubuntu/snap/chromium/353/.config/chromium/Default

Ubuntu 18.04 now uses snappy for installation.
I have installed Chromium from Ubuntu Software app

Comment 4

[Matthew N. [:MattN]]

> Profile Path	/home/ubuntu/snap/chromium/353/.config/chromium/Default

Hmm… looks like the Snap uses a different profile path… I think https://git.launchpad.net/~chromium-team/chromium-browser/+git/snappy-packaging/tree/snap may be the code for the snap but I'm not sure since there are a few and I don't see $CHROME_USER_DATA_DIR or --user-data-dir= getting set there[1]

I'm wondering what the significance of "353" is in the profile path? I'm guessing we can't hard-code that in our search. We need to figure out how to find this profile path in a reliable way.

[1] https://chromium.googlesource.com/chromium/src/+/master/docs/user_data_dir.md

Comment 5

[Matthew N. [:MattN]]

(In reply to Matthew N. [:MattN] (PM if requests are blocking you) from comment #4)
> > Profile Path	/home/ubuntu/snap/chromium/353/.config/chromium/Default
> 
> …
> I'm wondering what the significance of "353" is in the profile path? I'm
> guessing we can't hard-code that in our search. We need to figure out how to
> find this profile path in a reliable way.

jlorenzo, any suggestions for how we could reliably find this directory from Firefox? I guess we would need to do the same for the other channels of chromium too if they use different paths.

Comment 6

[Johan Lorenzo [:jlorenzo]]

That's a very good question! I'm not sure we can access the config of another snap. I didn't find the right permission to give. Moreover, we ship with the "strict" confinement[2], which restricts the access to the list given at [3].

Ken, Olivier, is there a way to add new whitelisted paths to the confinment, without setting the level to something lower than strict?

[1] https://docs.snapcraft.io/reference/interfaces
[2] https://searchfox.org/mozilla-central/rev/c621276fbdd9591f52009042d959b9e19b66d49f/taskcluster/docker/firefox-snap/snapcraft.yaml.in#5
[3] https://docs.snapcraft.io/reference/confinement

Comment 7

[Ken VanDine]

(In reply to Johan Lorenzo [:jlorenzo] from comment #6)
> That's a very good question! I'm not sure we can access the config of
> another snap. I didn't find the right permission to give. Moreover, we ship
> with the "strict" confinement[2], which restricts the access to the list
> given at [3].
> 
> Ken, Olivier, is there a way to add new whitelisted paths to the confinment,
> without setting the level to something lower than strict?
> 
> [1] https://docs.snapcraft.io/reference/interfaces
> [2]
> https://searchfox.org/mozilla-central/rev/
> c621276fbdd9591f52009042d959b9e19b66d49f/taskcluster/docker/firefox-snap/
> snapcraft.yaml.in#5
> [3] https://docs.snapcraft.io/reference/confinement

I know importing from another browser is an existing feature, however we consider a snap knowing about other snaps that are installed an information leak.  This is a powerful feature of snap confinement.

Comment 8

[Matthew N. [:MattN]]

I don't know much about Snaps but suppose a non-Snap Firefox build wants to import from a Chromium Snap, is that possible and how should we find the profile path?

Comment 9

[Ken VanDine]

A symlink to the current revision of the chromium snap's local data:

$HOME/snap/chromium/current

Comment 11

[:Gijs (out for now; he/him)]

(In reply to Ken VanDine from comment #9)

A symlink to the current revision of the chromium snap's local data:

$HOME/snap/chromium/current

It looks like on my machine this is actually under:

~/snap/chromium/common/chromium/

which makes sense, because it probably needs to stay accessible when the chromium version changes (ie after updates) - does that look right?

Comment 12

[Olivier Tilloy]

Yes, that's right. The location where the profile folder is stored for the chromium snap changed recently, it is now in ~/snap/chromium/common/chromium/.

Comment 13

[:Gijs (out for now; he/him)]

(In reply to Olivier Tilloy from comment #12)

Yes, that's right. The location where the profile folder is stored for the chromium snap changed recently, it is now in ~/snap/chromium/common/chromium/.

Thanks for confirming!

(In reply to Ken VanDine from comment #7)

I know importing from another browser is an existing feature, however we
consider a snap knowing about other snaps that are installed an information
leak. This is a powerful feature of snap confinement.

On macOS (on Mojave 10.14 and later) Safari now does this but only for their own stuff (that is, other applications can't get to Safari's data by default anymore, but Safari can get to Firefox/Chrome/...'s). On macOS, we can holepunch the sandbox by showing a file picker and allowing the user to pick the file they want the application to access, so that we can still offer bookmark import with user consent.

Does snap confinement have any similar way of holepunching the sandbox with user consent?

Comment 15

[Sarah Bird]

:Gijs just to follow up from 1667144, what should happen when there's two profile folders - one in the old location and one in the new snap location.

Comment 16

[:Gijs (out for now; he/him)]

(In reply to Sarah Bird from comment #15)

:Gijs just to follow up from 1667144, what should happen when there's two profile folders - one in the old location and one in the new snap location.

Yeeeeaaaah. It should probably use the most recently modified one. We can determine this if we can access the files, but not if we ourselves are in a snap package and can't read the snap files.

Comment 17

[Olivier Tilloy]

(In reply to :Gijs (back Dec 1; he/him) from comment #13)

Does snap confinement have any similar way of holepunching the sandbox with user consent?

Sorry for the very late reply. Not that I know of. That would really defeat the purpose of strict application confinement.

Comment 18

[:Gijs (out for now; he/him)]

(In reply to Olivier Tilloy from comment #17)

(In reply to :Gijs (back Dec 1; he/him) from comment #13)

Does snap confinement have any similar way of holepunching the sandbox with user consent?

Sorry for the very late reply.

No worries!

Not that I know of. That would really defeat the purpose of strict application confinement.

I'm confused. The toolkit (GTK or otherwise) filepicker can navigate to other files, that the snap package cannot otherwise access, right? And then the user can open those files with the snap application, right? (Or does snap completely break opening all files not in the snap package?) That doesn't "defeat the purpose of strict application confinement" - it allows users to pick a specific file that they want to give the file access to.

This is basically the same thing, from my perspective. We want a way for the user to say "yes, Firefox should have access to this file". Is that not possible? Or perhaps only via the toolkit filepicker, if the user manually navigates to the file in question?

Comment 19

[Olivier Tilloy]

(In reply to :Gijs (he/him) from comment #18)

This is basically the same thing, from my perspective. We want a way for the user to say "yes, Firefox should have access to this file". Is that not possible? Or perhaps only via the toolkit filepicker, if the user manually navigates to the file in question?

That's right, filepickers work because an out-of-process XDG portal is used under the hood (where available). This requires user confirmation.
So if the profile importer uses a filepicker, that would theoretically work. Automatically detecting an existing profile and importing it without user intervention wouldn't work.

Comment 20

[Mike Kaply [:mkaply]]

Clearing NI since question was answered by Olivier.

Comment 21

[Mike Kaply [:mkaply]]

Given that the only option is using a file picker, is this something we are willing to do? Or is this a WONTFIX.

It's simply not possible to autoimport things outside the Snap sandbox.

Comment 22

[:Gijs (out for now; he/him)]

(In reply to Mike Kaply [:mkaply] from comment #21)

Given that the only option is using a file picker, is this something we are willing to do? Or is this a WONTFIX.

It's simply not possible to autoimport things outside the Snap sandbox.

I think the importer dialog should check whether it's in a Snap or other kind of sandbox and provide some appropriate message, and then use a file picker in response to user request, yes.

Comment 23

[Mike Conley (:mconley) (:⚙️)]

We're going to have Ani explore this space to see what options we have.

Comment 25

[axtinemvsn]

Attachment: Bug 1467094 - Import from Chromium Snap Profile r=mconley

Comment 26

[Mike Conley (:mconley) (:⚙️)]

We've focused this bug to be about importing from Chromium when it's installed as a Snap package (and Firefox is not installed as a Snap package). I've filed bug 1818237 to work on importing when Firefox is installed as a Snap package.

Comment 27

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/45df0c21ab31
Import from Chromium Snap Profile r=mconley

Comment 28

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/45df0c21ab31

Comment 29

[Mike Conley (:mconley) (:⚙️)]

Release Note Request (optional, but appreciated)
[Why is this notable]:

Users on Ubuntu Linux that are trying to switch from the Chromium Snap package to Firefox will be able to import from Chromium if Firefox is installed (but only if Firefox is not installed as a Snap package).

[Affects Firefox for Android]:

No.

[Suggested wording]:

Ubuntu Linux users can now import their browser data from the Chromium Snap package. Currently, this will only work if Firefox is not also installed as a Snap package, but work is underway to address this!

[Links (documentation, blog post, etc)]:

None.

Comment 30

[Ina Popescu, Desktop QA]

Attachment: Migration Wizard_Ubuntu.7z

I've reproduced this issue in Nightly 109.0a1 (2022-11-30)(not installed as a Snap package) using Ubuntu 22.04.
Also I've checked in the latest Nightly 112.0a1 (2023-02-24)(not installed as a Snap package) where user can import now Browsing History and Bookmarks from Chromium Snap package(both with Chromium closed and opened).
As you mentioned, Browsing History and Bookmarks can not be imported from Chromium Snap package to Firefox installed as a Snap package.

Could you please confirm what items should be imported to Firefox on Ubuntu?

Currently Browsing History and Bookmarks are displayed as options on the "Items to Import" screen to be imported from Chrome or Chromium.
However in Nightly 109.0a1 (2022-11-30), user was able to import Cookies, Browsing History and Bookmarks from Chrome to Firefox. Please see screenshot Migration Wizard_Nightly 109.0a1.

Comment 31

[:Gijs (out for now; he/him)]

(In reply to Ina Popescu from comment #30)

Could you please confirm what items should be imported to Firefox on Ubuntu?

Currently Browsing History and Bookmarks are displayed as options on the "Items to Import" screen to be imported from Chrome or Chromium.
However in Nightly 109.0a1 (2022-11-30), user was able to import Cookies, Browsing History and Bookmarks from Chrome to Firefox. Please see screenshot Migration Wizard_Nightly 109.0a1.

Cookie import was removed in bug 1801051.

Comment 32

[Mike Conley (:mconley) (:⚙️)]

Yes, that's right - it is expected that Cookie importing from other browsers no longer appears. History and Bookmarks should be able to be imported. So it sounds like this fix is behaving as expected. Thank you!

Comment 33

[Dianna Smith [:diannaS]]

Relnote for nightly is available in https://www.mozilla.org/en-US/firefox/112.0a1/releasenotes/