Ask / Submit

http / https link handler broken? [answered]

asked 2019-01-08 13:25:47 +0300

Cosine gravatar image

Hei! After the upgrade to clickable http or https links do no longer open the web browser. This happens in mail, calendar and other apps which display links. In fact, nothing happens when tapping the link. I had some hope that upgrading to would fix this (somehow implicitly), but it didn't.

I'm not aware of any manual changes I might have made to config files, this might however have happened while installing and / or removing other apps like webcat.

Any idea what might be wrong or how to fix this?

edit retag flag offensive reopen delete

The question has been closed for the following reason "the question is answered, an answer was accepted" by Cosine
close date 2019-01-09 18:39:02.857527



Might be ovious, but I often have to tap links in mails several times until the browser opens.

Spark ( 2019-01-08 14:56:26 +0300 )edit

2 Answers

Sort by » oldest newest most voted

answered 2019-01-08 13:55:03 +0300

Direc gravatar image

Try Mimer, I fixed my settings with it.

I have no idea how or why my mime handlers broke, but that fixed them.

edit flag offensive delete publish link more



If you do not want to install Mimer you can also fix it via Terminal:

xdg-mime query default text/html               # query the default browser
xdg-mime default open-url.desktop text/html    # reset it to the default

Also check the content of /home/nemo/.local/share/applications/open-url.desktop

scharelc ( 2019-01-08 15:30:50 +0300 )edit

Thanks, the commands helped! For some reason this still pointed to webcat, although webcat is no longer installed.

It works as expected, the response to the query seems a bit strange, though. From

xdg-mime query default text/html

I get the following result:

which: no  in (/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/nemo/bin)

However, if I query as root

devel-su xdg-mime query default text/html

I get

Cosine ( 2019-01-08 16:40:21 +0300 )edit

I had exactly the same behavior also issued by webcat. I checked another Sailfish device and it shouldn't write the "which:"... line.

I wasn't yet able to find a cleaner fix. Also the file /home/nemo/.local/share/applications/open-url.desktop shouldn't be there at all. Deleting it did not broke anything on my device.

scharelc ( 2019-01-08 17:21:51 +0300 )edit

Now i found the solution. You have to delete this file (if it does not contain anything else than the html entry):

scharelc ( 2019-01-08 17:32:47 +0300 )edit

@Cosine If an answer helped and solved the issue, please mark the answer as accepted and close the question. Thanks!

Direc ( 2019-01-09 17:08:32 +0300 )edit

answered 2019-01-08 20:34:04 +0300

Cosine gravatar image

updated 2019-01-08 20:38:39 +0300

Here's the summary of how I solved it - thanks a lot to @scharelc, all the credits go to you!

I queried the current status and found that text/html should be handled by webcat, which was no longer installed

xdg-mime query default text/html

This should give a result like the following, in my case it referred to webcat.


Depending on your desired configuration, other values may of course be valid. If the result is not what you expect it to be, you can change it with this command

xdg-mime default open-url.desktop text/html  #open-url.desktop is the default value, this will trigger sailfish-browser to open html, you may replace this with your desired config file though. Refer to xdg-mime --manual for further details.

For some reason, ~/.config contained a file named mimeapps.list. This seems to have caused some inconsistencies when setting the new mime handler. The file contained two lines

[Default Applications]

Thus, the query for nemo resulted in

which: no  in (/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/nemo/bin)

After removing ~/.config/mimeapps.list, then applying this command again

xdg-mime default open-url.desktop text/html

the query result is now as expected. http/https links to html documents are now handled by sailfish-browser again.

Mimer did not do the trick for me, it allowed applying changes, but resulted in an additional line in the query response

which: no  in (/usr/local/bin: [....]

I did not try Mimer after removing mimeapps.list again, it might have worked then.

edit flag offensive delete publish link more


Thanks for providing the summary!

You could now mark it as the correct answer and close the thread if you like.

scharelc ( 2019-01-09 09:09:05 +0300 )edit

Question tools



Asked: 2019-01-08 13:25:47 +0300

Seen: 321 times

Last updated: Jan 08 '19