firefox fails to use the default profile from classic snaps

[zubozrout]

Hi,
I've recently made a clean install of Ubuntu 19.10 (development release) and have noticed that whenever I try to open a link from one of the snap apps (being it Slack or Skype) the links although opened in the default browser are being opened in a separate session of the web browser.

I am using Firefox and it is installed as a regular deb package (default).

This is wrong and causes issues with history, sessions and settings not being shared between these windows. Now I have the default browser I use + a separate session for Slack and another one for Skype. Not to mention Firefox also acts just like another Slack/Skype window so dash displays these as two instances of the same app.

To reproduce:
* Install Ubuntu 19.10 (not sure if upgrade from 19.04 would lead to the same behaviour).
* Confirm FFox is installed as a regular deb package.
* Install I suppose almost any snap app, although I've only reproduced this with Slack and Skype and haven't tried to install other apps.

System monitor also seems to be installed but when trying to open links from the about window - translators - individual names, it seems to do nothing.
On the other hand Gnome calculator which is also installed as a snap package opens the link in the about dialog correctly = in my default browser session.

```
:~# which gnome-calculator
/snap/bin/gnome-calculator
```

Thank you very much for looking into that.

[Oliver Grawert (ogra)]

snapd's userd just calls "xdg-open <URL>" in the users session when a link is clicked, i have opened a task against xdg-utils, it should make sure to call the right command to open urls in existing browser sessions.

the opening of "help://" urls via userd is an explicit limitation in snapd's userd that should get a separate bug so things are not being mixed here.

[zubozrout (zubozrout)]

I've just bumped into these two related mentions of the same issue:
https://forum.snapcraft.io/t/slack-opening-file-browser-firefox-and-chrome-in-the-snaps-context/8969
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1827770

The other launchpad report is older, so mine would be a duplicate I guess. But it is also expired for some reason.

[Zygmunt Krynicki (zyga)]

Hello

I've tried to reproduce this on a fully up-to-date Ubuntu 19.10 system, using gnome-calculator. I use firefox as my defualt browser. I clicked on the credits link in gnome-calculator and I got a new tab in my existing session.

I'm marking this bug as incomplete. Please clarify if the issue still persists for you.

[zubozrout (zubozrout)]

Ok, gnome-calculator snap seems fixed somehow. But Slack nor Skype still works. In Skype it crashes its own Firefox instance immediately, trying to open the browser - so only a crash dialogue gets opened. And in Slack this still opens in its own instance.

Please try to test this against these Snap apps.

[Maciej Borzecki (maciek-borzecki)]

I could reproduce this problem using 18.04.3 live CD using Slack and Atom. However, I don't think the problem is caused by snapd.

Slack, Skype and Atom are all classic snaps so they have full access to the system. With Slack installed, clicking on the 'get started' link was enough to get another Firefox window open. I collected the strace log. A relevant piece is here:

10782 execve("/usr/local/sbin/xdg-open", ["xdg-open", "https://slack.com/ssb/add"], 0xb6c9467b000 /* 75 vars */) = -1 ENOENT (No such file or directory)
10782 execve("/usr/local/bin/xdg-open", ["xdg-open", "https://slack.com/ssb/add"], 0xb6c9467b000 /* 75 vars */) = -1 ENOENT (No such file or directory)
10782 execve("/usr/sbin/xdg-open", ["xdg-open", "https://slack.com/ssb/add"], 0xb6c9467b000 /* 75 vars */) = -1 ENOENT (No such file or directory)
10782 execve("/usr/bin/xdg-open", ["xdg-open", "https://slack.com/ssb/add"], 0xb6c9467b000 /* 75 vars */) = 0
10784 execve("/usr/bin/which", ["which", "gnome-default-applications-prope"...], 0x560d5fb594a8 /* 75 vars */) = 0
10784 +++ exited with 1 +++
10782 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=10784, si_uid=999, si_status=1, si_utime=0, si_stime=0} ---
10785 execve("/usr/bin/gio", ["gio", "help", "open"], 0x560d5fb594a8 /* 75 vars */) = 0
10785 +++ exited with 0 +++
10782 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=10785, si_uid=999, si_status=0, si_utime=0, si_stime=0} ---
10786 execve("/usr/bin/gio", ["gio", "open", "https://slack.com/ssb/add"], 0x560d5fb594a8 /* 75 vars */) = 0
10789 +++ exited with 0 +++
10786 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=10789, si_uid=999, si_status=0, si_utime=0, si_stime=0} ---
10790 execve("/usr/local/sbin/firefox", ["firefox", "https://slack.com/ssb/add"], 0x563485f1c6e0 /* 77 vars */) = -1 ENOENT (No such file or directory)
10790 execve("/usr/local/bin/firefox", ["firefox", "https://slack.com/ssb/add"], 0x563485f1c6e0 /* 77 vars */) = -1 ENOENT (No such file or directory)
10790 execve("/usr/sbin/firefox", ["firefox", "https://slack.com/ssb/add"], 0x563485f1c6e0 /* 77 vars */) = -1 ENOENT (No such file or directory)
10790 execve("/usr/bin/firefox", ["firefox", "https://slack.com/ssb/add"], 0x563485f1c6e0 /* 77 vars */) = 0
10791 +++ exited with 0 +++

Notice how slack attempts to run xdg-open (and does so successfully at some point), then it proceeds to run `gio open ..`, and again does that successfully, finally it just runs firefox with the URL. I believe this is what triggers the new window to appear.

Another observation for Slack on 18.04 is that gnome-shell groups the Firefox window *with* the slack one.

I tried diffing the environment between the inside and outside of snap:

--- in-shell 2019-10-17 13:43:59.474529198 +0000
+++ in-snap-shell 2019-10-17 13:44:09.186624002 +0000
@@ -2,13 +2,14 @@ CLUTTER_IM_MODULE=xim
 COLORTERM=truecolor
 DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/999/bus
 DESKTOP_SESSION=ubuntu
+DISABLE_WAYLAND=1
 DISPLAY=:0
 GDMSESSION=ubuntu
 GJS_DEBUG_OUTPUT=stderr
 GJS_DEBUG_TOPICS=JS ERROR;JS LOG
 GNOME_DESKTOP_SESSION_ID=this-is-deprecated
 GNOME_SHELL_SESSION_MODE=ubuntu
-GNOME_TERMINAL_SCREEN=/org/gnome/Termi...

[Zygmunt Krynicki (zyga)]

Recently we noticed that XDG_RUNTIME_DIR is set to a custom value for both strictly and classically confined snap applications. It may be the case that adjusting the runtime directory for a test shows that a remote window is not opened.

I'm not proposing a solution yet but perhaps we can at least understand the cause.

[Zygmunt Krynicki (zyga)]

Given Maciek's comment about reproducing this with classic snaps I'm marking this as confirmed.

Interested parties can keep track of https://github.com/snapcore/snapd/pull/7659 where this issue may be resolved for _some_ snaps but if confirmed, the same cause is affecting all the strictly confined apps.

Marking as confirmed.

[Ian Johnson (anonymouse67)]

I am unable to reproduce this with the classic slack snap and core stable (2.42.1) on Ubuntu 19.04. I don't believe that zyga's patch has been released yet although it is merged so one could test on edge channel of core/snapd.

[Pål Andreassen (paal-andreassen)]

I can reproduce this with Ubuntu 19.10 and snapd 2.42.1

slack in classic mode. All clicked links opens Firefox in a new session where I'm not logged in, dont have any plugins etc.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Ian Johnson (anonymouse67)]

@paal-andreassen do you have firefox installed as a snap or as a deb?

[Pål Andreassen (paal-andreassen)]

Firefox is installed as a deb.

tor. 14. nov. 2019, 22:45 skrev Ian Johnson <email address hidden>:

> @paal-andreassen do you have firefox installed as a snap or as a deb?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1835024
>
> Title:
> Links triggered within most snap apps open in a separate browser
> session
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/snapd/+bug/1835024/+subscriptions
>

[Michev (d-michev)]

I was struggle with the same problem for a several weeks - all urls from snap apps were opened in different Firefox instances.
Today I finally figured it out - Open some url from snap app. Navigate this instance to `about:profiles` . Make sure that setted as default profile is the same as the one when you open Firefox normally. In my case this was `default-release` profile. Once you set it as default you are done. All links will be opended in your normal Firefox instance.

[Billy Bryant (billyjbryant)]

Setting the default profile to `default-release` fixed the problem for me as well.

[Omer Omer (omeromer)]

Comment #13 is a good workaround, but this is still a bug that needs to be resolved

[vic (wheresvic-sd)]

I can confirm that this bug exists on a fresh install of 20.04 as well.

Changing the firefox profile to that of `default-release` for the firefox session opened via Slack solves the problem but it would be wonderful if it could work seamlessly out of the box :)

[Ajith R N (trytoinnovate)]

I can confirm in too,fresh installation of 20.04, almost all the snap apps behaves this way, slack, VS Code, Android Studio etc ..

[Charles Michael Peszczynski Ritchea (novaterata)]

I just wanted to comment that this is more than just Slack "owning" apps opened from inside Slack. It also messes up the audio/video setup inside the "owned" app. For example, if I launch snap Slack before Chrome and try to join a Zoom call from Slack, then my A/V options are limited only to the built-in devices in my laptop. This makes Zoom unusable for me, so I have to make sure I always launch Chrome before Slack.

[Luis Alberto Pabón (copong)]

Problem remains in 20.10

[Sebastien Bacher (seb128)]

That's a firefox issue, the problem is there
https://sources.debian.org/src/firefox/82.0-1/toolkit/profile/nsToolkitProfileService.cpp/?hl=1840#L1823

The classic snap call the default browser from the system but from the snap environment that has SNAP_NAME defined or firefox has code to disable profiles in such cases...

The issue is easy to trigger using the deb, just do 'SNAP_NAME=bug firefox https://www.ubuntu.com'

[Olivier Tilloy (osomon)]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36

Steps to reproduce:

It's been reported several times on https://forum.snapcraft.io/ that when invoked from an application packaged as a classic snap¹ to open a hyperlink, firefox installed as a deb package (on Debian/Ubuntu) opens with the wrong profile by default.
This issue was investigated in https://launchpad.net/bugs/1835024, and we found out that the culprit is nsToolkitProfileService::IsSnapEnvironment()².

To reproduce the issue, ensure that a firefox window is open, then from a terminal run `SNAP_NAME=foobar firefox http://example.org`.

¹ https://snapcraft.io/docs/snap-confinement
² https://hg.mozilla.org/mozilla-central/file/tip/toolkit/profile/nsToolkitProfileService.cpp#l1838

Actual results:

This opens the requested URL (http://example.org) in a separate firefox window, with a different profile than that of the already open firefox window.

Expected results:

This should have opened the requested URL in a new tab in the same window that was already open.

[Olivier Tilloy (osomon)]

Good catch Séb! I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1674150 to track the bug upstream.

[Olivier Tilloy (osomon)]

Created attachment 9184555
Bug 1674150 - Check for the actual snap name when detecting whether running as a snap.

[Virginia-balducci (virginia-balducci)]

Hi Oliver,

Thank you for your report.

I was unable to reproduce this issue on Firefox Release version 81.0 (64-bit) Mozilla Firefox for Ubuntu canonical 1.0 , but I did reproduce the issue by downloading Firefox Nightly 84.0a1 (2020-11-14) (64-bit) and installing it on a different location (for example in Desktop Folder "Nightly").

I'll add this ticket to the Widget GTK component in the hope their team can take a look at this and share their feedback.

Regards,
Virginia

[Olivier Tilloy (osomon)]

(In reply to Virginia Balducci from comment #2)
> I'll add this ticket to the Widget GTK component in the hope their team can take a look at this and share their feedback.

Thanks for triaging Virginia. Unfortunately the patch¹ I submitted almost a month ago hasn't received any feedback yet. How do I get someone to look at it?

¹ https://phabricator.services.mozilla.com/D95171

[Jlorenzo-m (jlorenzo-m)]

Olivier reached out to me on Element. I looked at the patch and it seems the owner of `nsToolkitProfileService.cpp` is :mossop these days[1]. Would you have the bandwidth to review this patch, Dave?

[1] https://hg.mozilla.org/mozilla-central/log/93fabad45659d172b723c9606215d3acaab54df1/toolkit/profile/nsToolkitProfileService.cpp

[Stransky (stransky)]

I'm Gtk peer so you can ask me to review linux/gtk code.

[Dtownsend (dtownsend)]

I vaguely recall some plan to distribute devedition as a separate snap at some point which this would break but it looks like that hasn't happened so this is fine. I really wish there was a sane API to detect this though, environment variable detection always seemed likely to be flakey.

[Dtownsend (dtownsend)]

*** Bug 1680439 has been marked as a duplicate of this bug. ***

[Dluca-9 (dluca-9)]

Hi,
Phabricator show this bug has this tag : testing-exception-other (Please leave a comment explaining why).

Removing check-in needed because of that.

[Pulsebot (pulsebot)]

Pushed by <email address hidden>:
https://hg.mozilla.org/integration/autoland/rev/51d1c7feaa42
Check for the actual snap name when detecting whether running as a snap. r=stransky

[Apavel-2 (apavel-2)]

https://hg.mozilla.org/mozilla-central/rev/51d1c7feaa42

[Rodrigo (ro-goab)]

This error is extremely annoying, in my case I am using slack and chrome and it is also affected.

[Wm-5 (wm-5)]

This is back. `SNAP_NAME=foo firefox` (when Firefox is not installed as a snap) opens up the wrong profile in FF 104, and it appears the check for a specific snap name has been removed.

[Dtownsend (dtownsend)]

(In reply to Sophie Winter from comment #11)
> This is back. `SNAP_NAME=foo firefox` (when Firefox is not installed as a snap) opens up the wrong profile in FF 104, and it appears the check for a specific snap name has been removed.

It would be best to file a new bug for this. It will have been regressed by bug 1297520

[Mozilla-kaply (mozilla-kaply)]

1. Why are you setting SNAP_NAME?
2. That made it so we don't check SNAP_NAME at all (only SNAP_INSTANCE_NAME) so I don't think it should have affected this (unless I'm reading my own code wrong :) )

[Dtownsend (dtownsend)]

(In reply to Mike Kaply [:mkaply] from comment #13)
> 1. Why are you setting SNAP_NAME?
> 2. That made it so we don't check SNAP_NAME at all (only SNAP_INSTANCE_NAME) so I don't think it should have affected this (unless I'm reading my own code wrong :) )

The different environment name is one thing. But because we no longer check that the name is "correct" any snap app calling a non-snap Firefox will now cause Firefox to think it is running as a snap again.

[Mozilla-kaply (mozilla-kaply)]

> The different environment name is one thing. But because we no longer check that the name is "correct" any snap app calling a non-snap Firefox will now cause Firefox to think it is running as a snap again.

Doh. Definitely file a bug. I'll update the patch.

[Dtownsend (dtownsend)]

(In reply to Mike Kaply [:mkaply] from comment #15)
> > The different environment name is one thing. But because we no longer check that the name is "correct" any snap app calling a non-snap Firefox will now cause Firefox to think it is running as a snap again.
>
> Doh. Definitely file a bug. I'll update the patch.

For reference this is bug 1791442