How to stop Zoom from stealing URI associations when installing with FlatPak?

Support & Help Requests
,
#1

Since MATE 22.04 comes with FLATPAK; I decided to try out how the zoom and MsTeams sandboxes work....

Ever since installing Zoom Flatpak I've noticed that many web-links (like telephone numbers) that should not be associated to ZOOM are now being opened by ZOOM. I'd like to maintain Zoom assocition only for zoommtg and nothing else.

Looking inside var/lib/flatpak/exports/share/applications/mimeinfo.cache reveals that zoom is stealing file and URI associations for TEL (telephone) CALLTO as shown below

[MIME Cache]
application/x-zoom=us.zoom.Zoom.desktop;
x-scheme-handler/callto=us.zoom.Zoom.desktop;
x-scheme-handler/msteams=com.microsoft.Teams.desktop;
x-scheme-handler/tel=us.zoom.Zoom.desktop;
x-scheme-handler/zoommtg=us.zoom.Zoom.desktop;
x-scheme-handler/zoomphonecall=us.zoom.Zoom.desktop;
x-scheme-handler/zoomus=us.zoom.Zoom.desktop;

How to stop it from stealing all these other associations?

#2

Haven't you essentially already answered this yourself? :slight_smile:

Rip out the mimetypes that it shouldn't be stealing, then disassociate them (if necessary) via caja or terminal, and sudo chmod -w the file so it can't just immediately steal them back again next time it updates. That should do it.

Failing that, if you'd prefer not to edit any of those files, you'll have to steal them back by creating your own list of mimetype handlers to take precedence. Unfortunately this is fairly poorly implemented in Linuxland, but man mimeinfo will tell you where to put the files, and then update-desktop-database will actually make them work properly.
If you go this route, put it all in a script for when the next Zoom update blows all your changes away again!

1 Like
#3

Thank you for your detailed response! I found that most of the x-scheme-handlers are in ~/.config/mimeapps.list does that association supercede the flatpaks?

J

#4

Hello jonpolak

Is there nothing in the Flatseal settings that helps? :thinking:

#5

Sorry, IDK enough about flatpak to answer that. If not though, the answer is still fundamentally the same: it'll just be that the file needs to either be put at the top of whatever flatpak's priority list is, which hopefully is documented somewhere on fdo/whatever.