[Bug]: PWAs cannot be ran again on NixOS

VictorGamerLOL commented 1 month ago

Pre-Submission Checklist

[X] I have checked the existing/closed issues to ensure this issue has not already been reported.
[X] I am using the latest supported version of the browser.
[X] I have tried disabling all browser extensions/add-ons to rule out interference from these.
[X] I have tried clearing the browser cache and cookies.
[X] I have tried to create a new profile and the issue still occurs.
[X] I have provided detailed step-by-step instructions on how to reproduce the issue.
[X] I have included relevant screenshots or console outputs.
[X] I have checked this problem is not ocurring in the latest version of Firefox ESR.
[X] This issue is specific to this browser and does not occur in other browsers.

Bug Summary

Floorp assumes its own binary is stored in /usr/bin when making the desktop entry for a PWA and fails to launch the PWA if floorp does not have a binary in that location.

Reproduction Steps

Get NixOS
Add floorp to your user packages
Run floorp and install a PWA
Close the PWA
Try to run it from your DE's application launcher

Expected Behavior

The PWA opens.

Actual Behavior

Error command not found

Screenshots

Browser Version

11.13.2

Operating System

Linux 6.9.1-zen1 #1-NixOS ZEN SMP PREEMPT_DYNAMIC Tue Jan 1 00:00:00 UTC 1980

Additional Context

The about:support page does detect that the browser binary is located at somewhere like /nix/store/y7n2m06rv3zi7qjkbxmaff6qmw6ih0rz-floorp-11.13.2/lib/floorp/floorp. However, Floorp should not rely on a store path being consistent as it can change anytime. The path that can be relied on in this case is /etc/profiles/per-user/USERNAME/bin/floorp

I know NixOS is not a supported distro but I kindly ask you to fix this one thing and it will probably just work out of the box.

TheChilledBuffalo commented 1 month ago

This seems like an easy fix. Just to clarify, the command used to run Floorp from the terminal is still floorp right? Or is it different on NixOS?

VictorGamerLOL commented 1 month ago

This seems like an easy fix. Just to clarify, the command used to run Floorp from the terminal is still floorp right? Or is it different on NixOS?

Yep, the command without the path still is floorp.

jficz commented 1 month ago

The path that can be relied on in this case is /etc/profiles/per-user/USERNAME/bin/floorp

Not true. There are various places a profile path can be built from in NixOS. For example /etc/profiles does not even exist on my NixOS system.

The "proper" fix is to not to make any assumptions about paths and rely on $PATH instead.

VictorGamerLOL commented 1 month ago

The path that can be relied on in this case is /etc/profiles/per-user/USERNAME/bin/floorp

Not true. There are various places a profile path can be built from in NixOS. For example /etc/profiles does not even exist on my NixOS system.

The "proper" fix is to not to make any assumptions about paths and rely on $PATH instead.

Ok thank you I didnt know that I was only using nix for about 2 months now

TheChilledBuffalo commented 3 weeks ago

@VictorGamerLOL @jficz Hey guys, so I looked into this issue. Could you open the Browser Console in Floorp and run the following command and see if it gives the right path to the Floorp binary?

Services.dirsvc.get("XREExeF",Ci.nsIFile).path

jficz commented 3 weeks ago

That's one weird looking command :)

v11.13.3 nixos - 1.0

edit: disregard previous picture - wrong console

This is the command output (in my case): "/nix/store/bbkrr3fr5mwajv4kc5v3whi59qjabndy-floorp-11.13.3/lib/floorp/floorp"

jficz commented 3 weeks ago

@TheChilledBuffalo not sure if you're familiar with NixOS - in case you are not, this is how paths to applications (or, "packages") look like in Nix (OS).

Generally speaking, this path (or rather the weird hash after store/ part) changes with each package update. Technically it is a little more complicated but the details are not important in this case. The takeaway is you really can't know in advance what the path will be exactly.

TheChilledBuffalo commented 3 weeks ago

The path changes with each update? Wow ok... Then there's really no way this issue can be fixed then.... Unless you reinstall all your PWAs after each update, which isn't really practical...

jficz commented 2 weeks ago

I have exactly zero XP with PWAs, I just stumbled upon this issue accidentally because it mentioned NixOS :)

I would like to do some tests tho, @VictorGamerLOL can you pls elaborate on how did you create the desktop shortcut? I can't find a way to do it...

TheChilledBuffalo commented 2 weeks ago

@jficz If you are using the latest version of Floorp desktop entries should be created automatically when you install a PWA. It's stored in the ~/.local/share/applications directory

jficz commented 2 weeks ago

@TheChilledBuffalo so I see that the .deskop file is created with hardcoded path for Exec:

...
Exec=/usr/bin/floorp --profile .....
...

Which means the code that generates the .desktop file code probably has this path hardcoded or somehow (wrongly) inferred from the running platform or something like that. Otherwise I would assume it would use the actual path of the current running binary, which, on Nix(OS) is /nix/store/<hash>-floorp-<version>/lib/floorp/floorp (as returned by the function you suggested to try) or maybe the the path the binary was executed from (on NixOS that is usually a symlink in various places, depending on how the environment is built).

In such case I think it shouldn't be such a big issue to change that particular part of code to generate just Exec=floorp --profile ..., that should work on any platform that supports $PATH or equivalent.

I'm totally unfamiliar with Firefox codebase and I have no idea where to look for the code in question. A few naive greps yielded no results :/ Can you pls maybe point me where to look? Thanks!

jficz commented 2 weeks ago

@VictorGamerLOL as a workaround, you can update the .desktop files in ~/.local/share/applications manually - remove the /usr/bin prefix from the Exec= line, that should work

TheChilledBuffalo commented 2 weeks ago

@jficz Thank you for your research and as you said, using just floorp is a good idea. But recently we changed the code to dynamically find the location of the binary and not hardcode it to /usr/bin/floorp for example. We changed it to use the command that I had requested you to run that day:

Services.dirsvc.get("XREExeF",Ci.nsIFile).path

But even that has its issues because you said the binary location changes with each update. Anyways, let's wait till the next version and we'll consider using floorp. But the issue with using just floorp is, if someone has an alias or something it wouldn't work... Linking directly to the location of the binary is the safer route...

jficz commented 2 weeks ago

if someone has an alias or something it wouldn't work...

Interesting thought. Aliases are usually shell-specific and I'm not sure how or even if they will be evaluated in the process of executing the .destop file by whatever means the DE does.

Maybe I misunderstand what you mean, I tried this little experiment:

~/.local/share/applications $❯ alias floorp="echo nope"
~/.local/share/applications $❯ floorp
nope
~/.local/share/applications $❯ grep Exec floorp-PWAmp\ music\ player-\{82398e3f-a1d9-4453-bd4d-7da9b353fae9\}.desktop 
Exec=floorp --profile <...>
~/.local/share/applications $❯ gio launch floorp-PWAmp\ music\ player-\{82398e3f-a1d9-4453-bd4d-7da9b353fae9\}.desktop 

<...works...>

edit: made the example slightly more expressive

Floorp-Projects / Floorp