[Bug]: PWAs cannot be ran again on NixOS

[VictorGamerLOL]

[Bug]: PWAs cannot be ran again on NixOS

[jficz]

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.

[TheChilledBuffalo]

@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

[TheChilledBuffalo]

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]

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.

[VictorGamerLOL]

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]

@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]

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]

@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]

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]

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...

[jficz]

@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]

@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]

@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]

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