Issue with Ubuntu 22.04, does not open web browser, instead opens mime-type file associated application.

[Nbjohnston86]

I found this out by accident, when troubleshooting a problem with someone else's application, but hey! I know what the issue is (Although, I do not know how to fix it, I can at least identify it!)

How to reproduce this issue:

gedit ~/.config/mimeapps.list (you can use any text editor, really, I just chose gedit)

Once open, under [Default Applications] replace the line containing text/html= with text/html=gedit.desktop
If the line does not exist, add text/html=gedit.desktop instead. (Again, any text editor with a .desktop file will do.

Now that that's set up, use the function that calls: open_browser_internal, and is a standard file system path to an html document.
Example: /home/username/index.html
This will instead open up the file in the text editor you chose.

The problem is this: https://manpages.ubuntu.com/manpages/focal/man1/xdg-open.1.html

xdg-open opens a file or URL in the user's preferred application. If a URL is provided the
URL will be opened in the user's preferred web browser. If a file is provided the file
will be opened in the preferred application for files of that type. xdg-open supports
file, ftp, http and https URLs.

This means that if a file path is provided rather than a URL, and is a valid mime type, it will open the related non-browser application instead. This is definitely an edge case, but hey, it didn't open the default browser!

[Nbjohnston86]

I was not satisfied with having no potential solution, so I found a couple links that offer a potential solution, but I will not say it is the solution outright. But at least it's something to chew on:

to repeat what was already said:

xdg-open supports file, ftp, http and https URLs.

So, I had a thought to fix the problem. Convert the file path into a URL, I found this on Stack Overflow:
https://stackoverflow.com/questions/68918372/convert-filename-to-uri-in-rust
This uses the url crate, which seems to be a crate you're already using. So the only thing left to do at that point is to detect if it's a file path instead of a URL. And for that, I found this:
https://users.rust-lang.org/t/detect-url-or-path/25300
Which isn't an outright solution, but at least it has an idea of how to approach it, since xdg-open only supports a small list of valid URLs.

[amodm]

Thanks for the detailed notes, @Nbjohnston86. Saved me quite some time.

I was earlier going to respond by saying that text/html association means the user has chosen to specify the default browser as gedit (in this example), but it seems like the mime type association is still separate from the http scheme association.

This makes it a little tricky to solve, because ideally I'd like to avoid having to parse xdg config. In case you weren't aware, you can always solve this by overriding the $BROWSER environment variable (e.g. export BROWSER="firefox %s") as $BROWSER overrides everything else.

If that works for you, then I'd be inclined to just leave this issue open for up to 3 months to see if this is a common enough issue to justify the additional complexity of parsing xdg settings.

[amodm]

Also, can you please point me to the application which you were using (if it's open source, and you're ok sharing)? This is just to make sure that if indeed I end up solving for it specifically, then I notify the maintainer of it.

[Nbjohnston86]

Sure, I'll point you to the issue I originally found this in, even.

https://github.com/0xhiro/thebook/issues/2

I'm aware that I can fix this by setting that, it's just such an odd behavior I feel it's worth addressing anyways. I had to spend a couple of hours searching online through configuration guides and source code just to find out the specific intricacies of why my browser wouldn't open this file, when it seemed to open everywhere else.

And I was only able to figure this out because I'm a slightly more advanced linux user. I didn't technically choose this outright, as my original problem was it was opening with visual studio code, not gedit, and I think at one point it just did that without asking(I could be mistaken about that). A year ago, I definitely couldn't figure this out, that's for sure, haha. It would just seem broken on linux to the average user, but that's just my opinion.

It's hard to say how often this case could come up, so you could be right. If nothing else, it should at least be documented somewhere so people don't have to search as long as I did.

[ghost]

Well done @Nbjohnston86!

[amodm]

Thanks @Nbjohnston86, keep going with your linux pursuit!

I looked up more on this, and looks like [Added Associations] will be the right way to specify this in mimeapps.list, instead of [Default Applications]. When I tested it on an Ubuntu sandbox, it seemed to open the browser correctly for local html files, while still opening the html file in your configured editor when you double click on it from your file browser.

Can you give this a shot?

[amodm]

@Nbjohnston86 PR #58 fixes this in a proper way, so your default browser gets opened even if you have local file associations. This is particularly useful for projects like @0xhiro's, where local file is being opened instead of a URL, so thanks for bringing this up.

I have a few more things to include before this gets released, but feel free to give it a test by using the main branch

[dependencies]
webbrowser = { git = "https://github.com/amodm/webbrowser-rs" }

[ghost]

Thanks for the fix. Will test it and give feedback ASAP.

[amodm]

@0xhiro, I tested this with 0xhiro/thebook and it's working. Just logging my test results here, as I'll be making a release soon.

This issue also led me to expand the Consistent Behaviour promised by this crate, so double thanks to @Nbjohnston86 and you.

[ghost]

Thanks for this useful crate, looking forward to the next release. I'm sorry i couldn't contribute by testing, the holiday season got me occupied. I will ensure to fix the directory bug and publish a new version as soon as you make the bug fixes into a release.

[amodm]

Thanks for this useful crate, looking forward to the next release. I'm sorry i couldn't contribute by testing, the holiday season got me occupied.

No worries at all. Happy holidays 🎉 🎄

[ghost]

Thanks!

[ghost]

Any idea when that new release is coming?

[amodm]

The release should be out by this weekend, hopefully sooner. I'll ping here when that happens

[ghost]

Thanks!

[amodm]

@0xhiro, this is now released as v0.8.3

[ghost]

Awesome! Great work! and happy new year!

[amodm]

Great work! and happy new year!

Thanks, and wish you a happy new year as well