Do not register signal-desktop.desktop as handler for text/html

[sunjay]

• I have searched open and closed issues for duplicates

---

Bug Description

When installing signal, it appears to register itself as the handler for all text/html files. This causes the xdg-open command to open signal for all HTML files. This is undesirable because signal is not actually a browser.

Steps to Reproduce

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

Actual Result:

Running something like xdg-open foo.html opens Signal instead of opening a browser.

Expected Result:

xdg-open should not open Signal. Signal should not be registered as the handler for text/html files.

Workaround

Run the following command:

xdg-mime default firefox.desktop text/html

You may want to change firefox.desktop to something else if you prefer that.

Screenshots

Platform Info

Signal Version: v1.27.2

Operating System: Ubuntu Linux 64-bit (according to the website in the template)

More info:

Linked Device Version: N/A

Link to Debug Log

N/A

[scottnonnenberg-signal]

Interesting - this is not something we're doing. There's nothing having to do with 'text/html' in our .desktop file. Could be something Electron does, perhaps we can override it...

[sunjay]

Yeah I definitely thought it was odd too. 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.

There could also possibly be some configuration option that electron is using that only applies to newer versions of apt. Did you recently upgrade the version of Electron used to build this app?

[scottnonnenberg-signal]

Yep. v1.26.x was on Electron 4, and v1.27.x is on Electron 6.

[sunjay]

Okay. I just tested on 1.26.2 and could not reproduce the issue. Went back to 1.27.2 and the issue popped up again. If there were no changes in the signal app during that time that would have caused this I suggest opening a bug upstream in the electron repo to see if they can address it. Hope I've narrowed it down enough. :)

[bennlich]

This is happening for me in 1.27.2. Every time I open signal, it rewrites itself as my default application for opening text/html files :-/ Not just during installation.

[kenpowers-signal]

Reported an issue with Electron here: electron/electron#20382

[kenpowers-signal]

@sunjay Can you share the contents of /usr/share/applications/signal-desktop.desktop with us? If there is a line that starts with MimeType can you delete that line and run sudo update-desktop-database to see if that works as a temporary workaround?

[palday]

No MimeType:

[Desktop Entry]
Name=Signal
Exec=/opt/Signal/signal-desktop --no-sandbox %U
Terminal=false
Type=Application
Icon=signal-desktop
StartupWMClass=Signal
Comment=Private messaging from your desktop
Categories=Network;InstantMessaging;Chat;

[sunjay]

[Desktop Entry]
Name=Signal
Exec=/opt/Signal/signal-desktop --no-sandbox %U
Terminal=false
Type=Application
Icon=signal-desktop
StartupWMClass=Signal
Comment=Private messaging from your desktop
Categories=Network;InstantMessaging;Chat;

[mbiebl]

I've straced signal and noticed that it runs
xdg-settings set default-url-scheme-handler sgnl signal-desktop.desktop

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 wonder if xdg-settings get's confused about the sgnl type. It seems signal does not actually register such a mime type and maybe xdg-settings falls back to html in that case.

[sunjay]

There's a bunch of exploration going on in the electron/electron#20382 issue.

Here's a quote of my last response from there:

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).

I think the Signal team can fix this by renaming signal-desktop.desktop to signal.desktop or something. Any name works as long as you remove the -. @kenpowers-signal

[LAfricain]

Is there a workaround for this bothering problem? Even the help of some applications opens wiht Signal!

[mbiebl]

Until this is fixed, I've copied /usr/bin/xdg-settings to /usr/local/bin and added the following at the start of the script:

if echo "$@" | grep -q signal-desktop.desktop; then
       exit 0
fi

Also make sure to restore the original mime association for html files.

[EDIT: this is obviously a hack, and should be removed once fixed properly]

[scottnonnenberg-signal]

If you're running the beta, please update and let us know what you think! f790694

[ghost]

It looks like signal-desktop-beta_1.28.0-beta.2_amd64.deb has fixed it for me -- thank you, that was an annoying little bug :)

[LAfricain]

Where did you find the 1.28 deb?

[ghost]

apt-get install signal-desktop-beta

[ghost]

Just updated to 1.28.0 and this issue doesn't occur anymore 👍

[benjaoming]

Just updated to 1.28.0 and this issue doesn't occur anymore +1

@lgierth

Curious because I just reported this in #3754 - was the issue fixed after updating the .deb installation?

I'm still seeing the issue on 1.28 after an update.

[scottnonnenberg-signal]

@benjaoming I suspect that previous registrations will stay around. Updating to 1.28 will stop Signal Desktop from continuing to register itself.

[ghost]

Yeah confirm you'll have to set the registrations back to their proper values manually, but for me it sticks then

[benjaoming]

Yes, running xdg-mime default firefox.desktop text/html and then restarting Signal has correctly retained firefox.desktop as the handler.

However, the original application handler is not restored automatically, manually invoking xdg-mime default firefox.desktop text/html was required..

[RyanSquared]

@VictorKoenders and I just debugged the same thing and got similar results.

[ghost]

Yeah there's no way of restoring these to previous values - the fix in 1.28 is as good as it gets

[benjaoming]

@lgierth could do this in the Debian installer...

if xdg-mime query default text/html | grep -q signal
then
  echo "Fixing bug: Found Signal as mime type handler for text/html"
  if which firefox > /dev/null
  then
    echo "Restoring handler for text/html as Firefox"
    xdg-mime default firefox.desktop text/html
  elif which chromium-browser > /dev/null
  then
    echo "Restoring handler for text/html as Chromium"
    xdg-mime default chromium-browser.desktop text/html
  else
    echo "Could not find a handler, no handler set for text/html"
    xdg-mime default /bin/true text/html
  fi
fi

Test output:

➜  ~ xdg-mime default signal-desktop.desktop text/html
➜  ~ sh test.sh                                       
Fixing bug: Found Signal as mime type handler for text/html
Restoring handler for text/html as Firefox

[ghost]

Sure, I just meant that you have no idea which application was previously set for text/html. In my case it's sublime.desktop, for example. So you're not "restoring", but setting it to an application that you assume is a good choice for text/html :)

[benjaoming]

@lgierth agreed - I would prefer for normal users to have something or nothing as a handler for text/html rather than Signal.

Maybe /bin/true was a bad fallback as it will do absolutely nothing and give no user feedback when they try to open a file. Perhaps gedit is a more likely native and available application for the few systems that don't have Firefox nor Chromium.

[mbiebl]

I would prefer no automatic "fix-ups" of the "text/html" handler.