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
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 ?
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.
This should help you.
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
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!
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.
Yep, I tried chmod and chown and it doesn’t work
And chmod the directory they are in?
I would propose to try
chatter +i filenameThanks 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
That sounds like a bug in microtube, if it indeed creates an invalid .desktop file.
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.
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
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.
-
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).
-
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.
- 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.
oh, 4.3 came out as I was writing, excellent news! Time to revert my changes already 
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.
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…