Sailfish insists to open new netlinks with Fernschreiber 4.2.0.19/XA2

Bug Reports
#19

Well, I lack the knolwdge to join the discussion here, I can just report what happens in my phone: after creating my new open-url.desktop and doing

update-desktop-database $HOME/.local/share/applications/

the browser appeared again in the selection menu. Unfortunately it disappeared after a short time -without rebooting- along with the newly created open-url.desktop file…

I performed every step again and this time around also did

devel-su update-desktop-database /usr/share/applications/

So far so good, it also survived a reboot.
So thank you all for the solution.

My ~/.local/share/applications/
also have files from:

harbour-fernschreiber-open-url.desktop
harbour-webpirate-open-url.desktop
microtube-url.desktop

Two of them are popular apps that are veeery hard to stay away from.

Should we poke individual devs?
Or is there a way for sailors to handle these changes smoothly?

1 Like
#20

Noticed just that the Whatsapp opened a link in the Jolla browser. So, it seems to work ok from Android side.

#21

In 4.2.0 apps should be able to be more specific about which web domains they can handle, using the x-url-handler/ mimetype instead of x-scheme-handler/http(s). That would probably help with this problem.

6 Likes
#22

So I have freshly installed SFOS 4.2.0.21 on the XA2 and it also does not show me the browser, for selection to open a link.
is there maybe a patch in the meantime that you can install ?

#23

Can I read / intercept the link that is to be forwarded to an app? i.e. copy it to the clipboard?

I was able to work around this now with a trick. first installed Webcat and Mimer. Then the web browser in Miner changed to Webcat. This then also appears in the selection list. and then changed back to Browser. Now everything is as it should be. How long? remains to be seen.

#24

This should help you.

#25

Hey sailing fishers,

after I resized the /home/ vol incorrectly I flashed the new release yesterday. And from the beginning the Browser is not working correctly resulting in the open-with error described in this thread above.
After reading this thread I kinda already tried the solutions but without success. I can see the default browser in the openwith window but nothing happens if click it after. It seems like the browser is not opening and the desktop file is not working correctly

Anyone has the same?

I added open-url.desktop from

ls -la /usr/share/applications/|grep -E “open-url|h-browser”
-rw-rw-r-- 1 root root 466 Oct 4 18:07 open-url.desktop
-rw-r–r-- 1 root root 709 Jun 10 02:00 sailfish-browser.desktop

cat open-url.desktop

[Desktop Entry]
Type=Application
Name=Browser
Icon=icon-launcher-browser
NoDisplay=true
X-MeeGo-Logical-Id=sailfish-browser-ap-name
X-MeeGo-Translation-Catalog=sailfish-browser
MimeType=text/html;x-scheme-handler/http;x-scheme-handler/https;
X-Maemo-Service=org.sailfishos.browser.ui
X-Maemo-Object-Path=/ui
X-Maemo-Method=org.sailfishos.browser.ui.openUrl

cat sailfish-browser.desktop

[Desktop Entry]
Type=Application
Name=Web Browser
X-MeeGo-Logical-Id=sailfish-browser-ap-name
X-MeeGo-Translation-Catalog=sailfish-browser
Icon=icon-launcher-browser
Exec=/usr/bin/sailjail -p sailfish-browser.desktop /usr/bin/sailfish-browser %U
Comment=Sailfish UI application
MimeType=text/html;application/xhtml+xml;application/xml;text/xml;x-scheme-handler/http;x-scheme-handler/https;
X-Maemo-Service=org.sailfishos.browser.ui
X-Maemo-Object-Path=/ui
X-Maemo-Method=org.sailfishos.browser.ui.openUrl
[X-Sailjail]
Permissions=WebView;Audio;Location;Privileged;Internet;Downloads;Documents;Pictures;Videos;Music;Sharing;RemovableMedia;MediaIndexing
OrganizationName=org.sailfishos
ApplicationName=browser

After creating and rebooting I tried

update-desktop-database $HOME/.local/share/applications/
devel-su update-desktop-database /usr/share/applications/

This results in the browser beeing shown as an option but it seems not to open correctly cause nothing happens after clicking.

I do not know how to debug it further cause the desktop file seems to work the browser is opening from the menu. The problem seems to be the open-url file

Diffrent mimer actions with no success either

Please share some wisdom for a new fish

Cheers,

kk

1 Like
#26

the solution suggested by @carmenfdezb and @attah worked only for some time on my device: in less than a day open.desktop.url got deleted by itself. Tried many times, rebooting or not doesn’t affect this.

With my non-existent knowlwdge I feel this is not a problem with individual apps. It is about the browser disappearing from the list, due to some process erasing open.desktop.url from the system.

If Sailfish is left with only one option to open links it will use that one, in the OP case, Fernschreiber. @lumen it yould be interesting to know if you have other files other than
harbour-fernschreiber-open-url.desktop
in
/home/nemo/.local/share/applications

As @thigg says, this shouldn’t be about Fernschreiber…

If confirmed, may the title be tweaked?
I hope Jolla files (and fixes) the bug for what it is and does not overlook it as a Fernschreiber problem.

In the meanwhile, does anyone have an idea to make carmenfdezb 's solution stay? Thanks for any help!

How fix a borked MIME handler for links?
#27

Forgive me, but has no one tried to chown and chmod these files to prevent system from deleting?
Something like chmod 701 would give owner full perm, none to groups, and execute perm to system.
I would suggest doing those changes after doing update-desktop-database, of course.

#28

Yep, I tried chmod and chown and it doesn’t work

#29

And chmod the directory they are in?

#30

I would propose to try

chatter +i filename
#31

Thanks guys for the suggestions and thank you peterleinchen for the
chattr +i command, I tried it and while the general problem persists, I am somehow better off than before: open-url.desktop does not get deleted anymore.

In my /home/nemo/.local/share/applications I had url.desktop files from microtube, fernschreiber and web pirate. I got rid of the last two by deactivating the “integrate with mime type” option in the settings of each app, while microtube did not allow this.

I erased also mimeinfo.cache, so the output of
lsattr *
in /home/nemo/.local/share/applications, was

--------------e----- microtube-url.desktop

----i---------e----- open-url.desktop

Then I run
devel-su update-desktop-database /usr/share/applications/

So far so good, Browser appeared in the list again (along with microtube) when clicking on links. It lasted for a couple of days, and as long as mimeinfo.cache was not there, everything was fine.

Then I used microtube again and the following “bad” mimenfo.cache was created:

[MIME Cache]

x-scheme-handler/http=microtube-url.desktop;

x-scheme-handler/https=microtube-url.desktop;

it completely ignored open-url.desktop which was still there and links were opened with microtube.

At this point I thought it made sense to run

update-desktop-database $HOME/.local/share/applications/

but I got this output:

Could not parse file "/home/nemo/.local/share/applications/open-url.desktop": Key file does not start with a group

Any idea what to do next?

Sorry for the loooooong post…

1 Like
#32

That sounds like a bug in microtube, if it indeed creates an invalid .desktop file.

#33

Thanks, yes, microtube seems to be more aggressive as each time I use it, it causes changes to mimeinfo.cache that break things, while e.g. Fernschreiber will do nothing if I open it.
However, if I open Fernie and in settings I choose “Open-with-menu integration”, it will also create a “bad” mimeinfo.cache. And so does Web Pirate, meaning the problem is more general, I suppose.

On top of this, if I have nothing but open-url.desktop in home/nemo/.local/share/applications and run both

update-desktop-database $HOME/.local/share/applications/
and
devel-su update-desktop-database /usr/share/applications/

the mimeinfo.cache that gets created will be
basically empty with just this content:

[MIME Cache]

I thought it was supposed to get populated with the right entries from open-url.desktop

P.S. In my previous post I made a mistake about the very last command I run, I’ve edited it.

#34

I experience disappearance of Browser in 4.2 and solved it by creating open-url in local applications.
After 4.3 upgrade it was ‘duplicated’; btw. microtube was also duplicated.
So I removed concerned local -url files and regenerated desktop database (through update-database).
This solved it completely on my side.

1 Like
#35

Here I share a solution that seems to work for me, take it with the caveat that Charlemagne was probably more tech-savvy than I am.

  1. use file browser or terminal to erase every file in home/nemo/.local/share/applications except open-url.desktop (if you don’t have it, create in a text editor as suggested in the posts above).

  2. From the phone terminal run
    update-desktop-database $HOME/.local/share/applications/
    and
    devel-su update-desktop-database /usr/share/applications/

You will see that a new
mimeinfo.cache will be created and that it is basically empty with just this content:
[MIME Cache]
Good, at least it will not interfere. Let’s keep it so we can use it as a
“signpost” in the next step.

  1. quick test: try opening a link from sms, email or weather app (avoid opening other apps as they might interfere). If it works and browser is offered as an option, go back to terminal and make above changes “permanent” with
    devel-su chattr -R +i /home/nemo/.local/share/applications
    this way no application will change files in that folder and things should keep working.

Surely it is an ugly, temporary approach and I will definitely revert all these changes BEFORE next upgrade with
devel-su chattr -R -i /home/nemo/.local/share/applications
hoping sailors will have come with a fix.

#36

oh, 4.3 came out as I was writing, excellent news! Time to revert my changes already :slight_smile:

#37

No guarantees that your problem is identical. But there is a chance we experienced the same issue.
Btw. 4.3 is a preview release out this morning, I guess you know how to handle that.

#38

Sure, I will report here if updating doesn’t solve it.
I know shouldn’t, but I am on EA. I have a strong guinea pig instinct…