Electron is setting itself to be the default application for text/html files on Linux

[kenpowers-signal]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for an issue that matches the one I want to file, without success.

Issue Details

• Electron Version:
  • v6.0.9
• Operating System:
  • Linux Mint 19.2
• Last Known Working Electron version:
  • v4.2.2

Expected Behavior

Electron should not set itself as the default application for opening text/html files.

Actual Behavior

We are having users reporting that Signal sets itself as the default application for opening text/html files, both on installation and again while re-launching, but we did not set this up. See signalapp/Signal-Desktop#3602

To Reproduce

Via signalapp/Signal-Desktop#3602

1. Install signal on Linux Mint or Ubuntu
2. Run the command xdg-mime query default text/html
3. The output should be signal-desktop.desktop as shown below:

$ xdg-mime query default text/html
signal-desktop.desktop

[nornagon]

Can you reproduce this with a test case smaller than Signal? (e.g. does this happen with a trivial Electron app?)

[kenpowers-signal]

Unfortunately I suspect this may be an issue with apt or electron-builder but I'm unsure of how to verify. @sunjay reported in signalapp/Signal-Desktop#3602 (comment):

I did some further investigation and I think this might be an issue with apt-get. I tried the same procedure on a computer that had Linux Mint 19 (not 19.2) and did not encounter any problems. I then upgraded to Linux Mint 19.2 and was able to reproduce the issue using the procedure above. If the version of apt changed between those two versions, they may have introduced a bug.

I just tried reproducing with a fresh installation of Linux Mint 19.2. I installed nvm and ran nvm install stable then ran local and global installations of Electron. HTML files were still opening in Firefox though.

[nornagon]

OK, I'll close this then as it seems like it's not an issue with Electron itself.

[kenpowers-signal]

@nornagon We're having trouble tracking this down. Does electron expose any APIs to set the application as the default file handler for a given mime type?

[nornagon]

https://electronjs.org/docs/all#appsetasdefaultprotocolclientprotocol-path-args

on linux, it just calls xdg-settings. If it's a bug in apt, it's probably not calling it through Electron.

[mbiebl]

I'm also running into this issue and I straced signal:

[pid 710622] stat("/usr/bin/xdg-mime", {st_mode=S_IFREG|0755, st_size=42095, ...}) = 0
[pid 710622] clone(strace: Process 710623 attached
child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fbfe8287850) = 710623
[pid 710623] execve("/usr/bin/xdg-mime", ["xdg-mime", "query", "default", "text/html"], 0x5651ce12b1e8 /* 62 vars */ <unfinished ...>
...
[pid 710644] execve("/usr/bin/xdg-mime", ["xdg-mime", "default", "signal-desktop.desktop", "text/html"], 0x5651ce129958 /* 62 vars */) = 0

So indeed, signal / electron set's itself as default html handler on each start

[nornagon]

Electron never invokes xdg-mime, only xdg-settings. https://github.com/electron/electron/blob/b2652becebd94c83b91e4555db44e608a4086fcb/shell/browser/browser_linux.cc

So something other than Electron is invoking xdg-mime.

[mbiebl]

xdg-settings calls xdg-mime

[nornagon]

Ah, I didn't realise that. If the method in Electron is being called you should be able to find an invocation that looks like xdg-settings set default-url-scheme-handler signal-desktop.desktop

[mbiebl]

yeah, see my comment at signalapp/Signal-Desktop#3602 (comment)

apparently signal/electron calls xdg-settings set default-url-scheme-handler sgnl signal-desktop.desktop
The result is, that the default handler for html is switched

michael@pluto:~$ xdg-mime query default text/html
firefox.desktop
michael@pluto:~$ xdg-settings set default-url-scheme-handler sgnl signal-desktop.desktop
michael@pluto:~$ xdg-mime query default text/html
signal-desktop.desktop

I'm not sure whether this is a bug in signal, electron or xdg-settings fwiw. I'm just posting my findings so far

[sunjay]

I found a remotely related bug that says:

I've tracked down the issue, not sure how to solve it yet, desktop_file_to_binary treats filenames with a - in the format vendor-app.desktop so it is searching for browser.desktop in the chromium directory and failing. If "-" shouldn't be allowed in the desktop file filename there is a large number of broken files on this openSUSE Tumbleweed system, if they are allowed then desktop_file_to_binary needs fixing, i'll raise this on the xdg mailing list

And I can confirm that this does make a difference:

$ xdg-mime query default text/html
firefox.desktop
$ xdg-settings set default-url-scheme-handler sgl signaldesktop.desktop 
$ xdg-mime query default text/html
firefox.desktop

I think this is in fact an electron bug. Maybe not something that they can necessarily fix, but certainly something that can be documented (probably in electron-builder) and probably warned about.

[scottnonnenberg-signal]

No, it should be in the documentation for this call: https://electronjs.org/docs/api/app#appsetasdefaultprotocolclientprotocol-path-args

Called here - and why Signal Desktop re-registers itself on every startup, and not just on install:
https://github.com/signalapp/Signal-Desktop/blob/b05650fa4171a70ffd531cc9639037745b5e90fc/main.js#L876

I think we can safely reopen this bug.

[mbiebl]

Reading more about this, I think this is ultimately a xdg-settings bug.
It should properly handle desktop files with - in their name.
Second, the failure mode of xdg-settings seems broken: If it can't find the desktop file because of the -, why does it change the html default handler?

[mbiebl]

That said, it seems reasonable to use a desktop file name without a dash, i.e. signal.desktop until this issue in xdg-settings is fixed.

[argenos]

I'm running into this bug for an app that is also using electron. I created the desktop file manually and it doesn't contain any dashes, so I'm not sure that the bug is in xdg-settings nor what the difference is with the comment by @sunjay:

Any clue on what else could be happening here? What else could I look at?

[dlech]

It looks like @argenos has found the source of the problem: https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/180

Since xdg-settings is known to be buggy, could Electron be changed to use xdg-mime directly instead?

[dlech]

Another option could be to override the desktop environment detection using environment variables when calling xdg-settings since the bug only seems to be with GNOME3. (See https://gitlab.freedesktop.org/xdg/xdg-utils/-/blob/master/scripts/xdg-utils-common.in#L270)

i.e. set XDG_CURRENT_DESKTOP=X-Generic

[thriveth]

The bug also exists for me, using Obsidian, in the Awesome WM, so it is not only in Gnome 3.

[trustin]

This is essentially a bug of xdg-settings but it'd be nice Electron works around this issue by using xdg-mime instead of xdg-settings. Meanwhile, I put this script (~/.local/bin/xdg-settings) in my PATH as a workaround:

#!/bin/bash
if [[ "$1 $2" == "set default-url-scheme-handler" ]]; then
  DEFAULT_BROWSER="$(xdg-mime query default text/html)"
  /usr/bin/xdg-settings "$@"
  if [[ "$(xdg-mime query default text/html)" != "$DEFAULT_BROWSER" ]]; then
    echo "Reverting the default web browser to $DEFAULT_BROWSER"
    xdg-mime default "$DEFAULT_BROWSER" text/html
  fi
  exit 0
fi

exec /usr/bin/xdg-settings "$@"

[pamdemonia]

Just an additional fix for those looking for them.

Got this bug recently on Ubuntu 22.04 using etcher.

Couldn't find the problem using xdg-mime or xdg-settings (both had correct handler listed). Put @trustin script into my PATH as well, but still got the issue. (especially annoying as I am trying to learn Rust and everytime I do cargo doc it opens etcher which tells me the file is not a valid iso.)

This, however, fixed the issue:

1. opened this file: ~/.config/mimeapps.list in a text editor.
2. did a search for "etcher" and found an instance
3. moved the offending line from the "Default Applications" section to the "Removed Associations" section
4. added a semi-colon to the end of the line I just moved.

Voila! It worked.

Hope this helps someone out there!

pam

[grantm]

Not intending to re-open this issue, just adding a comment that others might find useful.

As others have mentioned, this seems to be caused by a bug in xdg-settings which some people have suggested only strikes when the name of the .desktop file for the electron app contains a "-". At my company we work around the problem as follows:

We use electron & electron-builder to package a customised version of element-desktop. The package generated by the upstream project includes a file called Element.desktop and that package does not exhibit the problem. Our build was generating a file called companyname-element-desktop.desktop and did exhibit the problem.

We tweaked the package.json to set the executableName to CompanynameElementDesktop (which is used both for the binary and for the .desktop file) and the new package no longer registers itself as the default app for text/html.

Our build script customises the build parameters in package.json using these commands:

DEB_VERSION_SUFFIX="1companyname1"
jq --arg versionSuffix "$DEB_VERSION_SUFFIX" '
  .name="companyname-element-desktop" |
  .productName="companyname-element-desktop" |
  .version=(.version + "-" + $versionSuffix) |
  .build.linux.desktop.Name="Companyname Chat" |
  .build.linux.executableName="CompanynameElementDesktop"
' < ./package.json > tmp.$$.json
mv tmp.$$.json ./package.json

and the relevant bits of the resulting package.json looks like this:

{
  "name": "companyname-element-desktop",
  "productName": "companyname-element-desktop",
  "version": "1.11.29-1companyname1",
  ...
  "build": {
    ...
    "linux": {
      "target": [
        "tar.gz",
        "deb"
      ],
      "category": "Network;InstantMessaging;Chat",
      "maintainer": "support@element.io",
      "desktop": {
        "Name": "Companyname Chat"
      },
      "executableName": "CompanynameElementDesktop"
    },
...