Emacs no longer opens links in the existing instance of firefox and the new one it opens is not using my profile

[mousetrappling]

As requested on reddit, opening an issue here.

OS: Ubuntu 20.04.4 LTS, Gnome 3.36.8 Emacs: GNU Emacs 28.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0) of 2022-04-06; installed from the current stable snap package Firefox: 99.0

To reproduce in emacs -q: M-x browse-url-firefox RET (url) (I’m using the wordle url to test but any url I put in place of my placeholder (url) in that command does the same).

Expected behaviour: the url is opened in my already running instance of firefox as a new tab or if there isn’t one then it runs a new instance of firefox that uses my profile.

Actual behaviour: the url is always opened in a new instance of firefox, this looks to the OS as if it is an Emacs window (the application bar shows me two Emacs windows not one Emacs window and one firefox window), this new instance of firefox doesn’t appear to be running my profile (I’m not logged in anywhere). Opening a second link will open it within this not-right instance of firefox.

The problem started after I upgraded both emacs and firefox (within a few hours and I don’t think I opened any links in between).

I’ve tried googling and all I can find is: https://emacs.stackexchange.com/questions/71275/how-to-open-firefox-with-default-bookmarks-and-add-ons-profile-when-clicking-url which I think is the same problem conceptualised a little differently.

If I open a terminal outside of emacs (just a normal terminal) and do xdg-open (url) then I get the expected behaviour. In emacs if I do: M-! xdg-open (url) then I get the buggy behaviour.

M-x browse-url-chromium RET (url) behaves as expected – i.e. the url is opened in the already running instance of chromium if I have one, and if a new instance is opened (because I don’t have one running) then the OS sees it as a chromium window not an emacs window and appears to use my profile.

Would the value of process-environment be useful? I can provide it if so, but it's rather long to just paste in if it's useless.

[mousetrappling]

Additional possibly relevant information I just thought of: Firefox is installed via apt, Chromium is installed via snap.

[mousetrappling]

I just tested it by logging in as a different user on my machine, so exact same software stack but none of my customisations including not my firefox profile. I get the same buggy behaviour with browse-url-firefox as I do when running as my own user, so I think I've ruled out my firefox profile being the problem.

[alexmurray]

So I can easily reproduce this by doing the following in a fresh Ubuntu 20.04 LTS VM:

snap run --shell emacs
xdg-open https://ubuntu.com

NOTE- internally xdg-open calls gio open https://ubuntu.com and this also results in the same.

FWIW I can also reproduce it using any other snap which uses 'classic' confinement, eg.

sudo snap install classic-snap-analyzer --classic
snap run --shell classic-snap-analyzer
xdg-open https://ubuntu.com # gio open https://ubuntu.com

But if we use something like the snap-store snap which has strict confinement it works fine. NOTE the snap-store snap uses the desktop plug and various snapcraft extensions to set up its environment though so I also checked with a much simpler snap that is a simple CLI util that uses strict confinement but which also plugs the desktop interface and this also works as expected (although it doesn't have gio internally).

So there must be something about the way snapd sets up the snap environment for classic mode which confuses gio I think - so I guess the next step is to try and figure out what gio is doing differently when run via emacs and see if we can influence it to run the same as it normally would.

[benprew]

I had a similar issue with emacs (via snap) opening a different profile compared to what the shell used. In my case, I had 2 profiles: "default" and "default-release". The shell (and gnome) would use "default-release" but emacs would use "default".

Removing the "default" profile via about:profiles fixed it for me.

For reference: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles?redirectslug=profile-manager-create-and-remove-firefox-profiles&redirectlocale=en-US

System details:

><> which emacs
/snap/bin/emacs

><> emacs --version
GNU Emacs 28.0.91

><> lsb_release -a
No LSB modules are available.
Distributor ID: Pop
Description:    Pop!_OS 21.10
Release:        21.10
Codename:       impish

><> which firefox
/usr/bin/firefox

[alexmurray]

So this may be a general issue with snaps that use classic confinement https://bugs.launchpad.net/snapd/+bug/1835024

[alexmurray]

Hmm actually it seems those issues have been fixed in both snapd and the Firefox snap already.

FWIW I can see on Ubuntu, the emacs snap ends up running under an AppArmor profile but in complain mode - as such when firefox is executed, it inherits this AppArmor profile and then also runs under this - which I believe then causes the Ubuntu dock to associate the Firefox window with the Emacs icon rather than the Firefox one.

We workaround this by running firefox manually outside of the emacs snap AppArmor profile:

snap run --shell emacs
aa-exec -p unconfined firefox

Then firefox appears to run as it's own application and is correctly associated with the Firefox icon on the Ubuntu dock. Will see if I can make this automatic (ie try and ensure the emacs snap itself runs unconfined and hence anything it then runs will also run unconfined).

[alexmurray]

I have just promoted this to the stable snap channel, closing this bug. Please let me know if the issue still persists but from my own testing this appears to work correctly.

[mousetrappling]

I just upgraded to the new snap, and it's not fixed the original problem – links still open in a different instance of firefox which has a different profile to my usual one (instead of opening in the already running firefox or opening a new firefox with my profile). However, it does now look to the system like it's a firefox window (not an emacs window) so that fix has worked.

I did a little bit more testing, in particular looking at what benprew said above. He's correct – the two different firefox profiles are something.default-release and somethingelse.default and the .default-release one is the one that I usually use and the one that's just .default is the one that emacs uses to open links. In the other user account on my machine the same was also true, so I removed the .default profile and emacs started opening links in the already running instance of firefox. So that works as a workaround.

I've held off on just applying that on my actual account as it still seems like a bug to me – why should emacs choose a different profile to the shell? Why are there two default profiles anyway? Is there a purpose to the other one that means I'll break something else by deleting it? But I can see that given there's a pretty easy workaround you might not want to spend the time on figuring out how to fix it (and it might not even be a problem in the emacs snap but a bug in something else), and if that's the case I'll just go ahead and delete the extra profile! :)

[alexmurray]

Ok I was able to reproduce this issue regarding the use of the incorrect profile and have just committed a fix in 7d892b6 - this should be available soon on the beta channel so if others could test this once it becomes available and report back that would be great. Thanks.

[mousetrappling]

Just switched to the beta channel, and links now open as I expect them to so it's fixed for me.

However, with that beta I'm seeing compilation errors again (like in #35), complaining about comp.el.gz not compiling. Is that something you're aware of or does it need an issue opening? I'm going to drop myself back to the stable one now but I'll save the errors from the Warnings and Async-native-compile-log buffers somewhere so I can paste them in an issue if you need them.

[alexmurray]

No this is not expected - and I can't reproduce it myself... but I see that others are mentioning similar things over in #30 so please make sure you leave a comment over there if you haven't already.

[alexmurray]

Ahh but I have an idea what this could be - let me see if I can come up with something.

[alexmurray]

Ok I think that hopefully 58411aa and https://github.com/alexmurray/emacs-snap/commit/978719677dcc0dcc73b2fd382657ad9c5330a000 should fix the native compilation errors - apologies for inadvertently reintroducing those.

I have triggered a rebuild of the snap and it should be available in the beta channel in the next couple hours. Can you please test this and let me know if it resolves the issue for you? Thanks.

[mousetrappling]

Sadly that beta appears totally broken. The only available message is:

if: Symbol’s value as variable is void: native-comp-driver-options

No buffers load other than scratch and Messages. Presumably the same problem as: #39

[alexmurray]

Ugh sorry for this - I have a fix in progress which I believe should resolve this - it is currently building so should be available in the beta channel in ~1-2 hours. Thanks for reporting this issue so quickly.

[alexmurray]

Ok updated snap build are available in the beta channel (for emacs 28.1) and the edge channel (for emacs 29.0.50) for amd64 at least - please let me know if these resolve the issue for you.

[mousetrappling]

Fixed for me :)

[alexmurray]

Excellent - apologies for the regressions, please feel free to create a new github issue if you come across any other oddness.