2

When I enter localhost:8888 in the address bar, the flatpak version of Firefox opens a dialog to choose an application to open the link. If I use http://localhost:8888 the page opens normally. I don't want to type http:// every time. Is there a way to restore the non-flatpak behavior of converting localhost:8888 to http://localhost:8888 or work around it just for localhost?

I believe what is happening is that localhost: is getting interpreted as a protocol named localhost instead of e.g. http or https. I have found that 127.0.0.1:8888 does work, but I would prefer localhost to work because loc<Tab> is usually enough to open what I want but even tab completion hits this protocol issue. 127<Tab> does not give me good tab completions but maybe it would if I used it more so 127.0.0.1 got more weight in the suggested URLs.

Improve this question
4
  • Have you tried this solution?
    – Ramhound
    Commented Jun 24, 2021 at 21:58
  • I tried some of the options there but they didn't help. Some options I did not try because they require giving up features of the address bar that I would like to keep.
    – ws_e_c421
    Commented Jul 19, 2021 at 19:54
  • You can edit your question. I would do that since, I don't know what solutions you have tried, and by not knowing that information I can't perform research
    – Ramhound
    Commented Jul 19, 2021 at 19:56
  • I just noticed an important clue while checking which things do not work -- I only see this behavior when using the flatpak version of Firefox, not the OS packaged version.
    – ws_e_c421
    Commented Jul 19, 2021 at 20:52

1 Answer 1

Reset to default
0

This is actually a known issue. The problem is that there is no API for the flatpak of Firefox to query for a localhost protocol handler and fall back to treating the term as an address if there is none like it can outside of the flatpak sandbox. Firefox can only pass the potential protocol to a handler outside of the sandbox. This is my interpretation of the discussion in the linked Bugzilla ticket.

I believe one workaround might be to register a localhost protocol handler that calls xdg-open again on http://localhost:<port+rest of URL> but I have not had time to experiment with this.

I am posting this as an answer to highlight that this is a known issue without a good workaround but not marking it as accepted. If someone comes up with a good workaround, it would be welcomed.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .