Implement System Integration on macOS

[TitanNano]

From #31 (review):

System integration (basically the things that are already in Windows and Linux integrations; I will probably need some help here)

• When installing PWA site
  • It needs to create an application shortcut/entry with a required icon, name, description, keywords and categories (if macOS doesn't support some of those properties, it's fine, but it needs at least an icon and name) that launches the site.
  • It should also add shortcuts/links to the entry with actions from the manifest. I don't know if this is supported on macOS or how is it called, but on Windows these are jump list tasks and on Linux desktop actions. This functionality is not needed as much as others, so it can be added later.
  • That entry needs to be added to the user-specific app menu/list. I think this could be done by creating a custom .app bundle with all those properties that is installed to ~/Applications.
  • If macOS has some way to list/manage/uninstall apps (such as Add or Remove Programs page in Windows), the site should be registered there, so the user can uninstall it directly from the system.
• When uninstalling PWA site
  • All system integration entries should be removed.
• When launching PWA site
  • The window should have a correct site icon. Maybe this can be done in app entry, maybe it also needs some configuration at run-time.
  • The window should not merge/group with other Firefox and PWA windows. On Windows, this is done using Application User Model ID, and on Linux it uses --class command argument when launching Firefox to set WM_CLASS.
• Maybe I also forgot something that is done for Windows and Linux and should also be done here.

[TitanNano]

@filips123 I still have to do some clean up, but it looks promising so far.

[ayushhroyy]

Hey, you are doing a great job there! just dont dump this project like mozilla did. Also can we get the expected time for macOS pwa support!? I just don't use firefox and have to switch because of pwa only. Have a good day Dattebayo!

[TitanNano]

@filips123 I hit a bit of a road block here. macOS requires each Application bundle to launch its own process, and a single process can not provide windows for more than one app.
This means we have to launch a new runtime process for each PWA, but with the currently shared profile that's not possible.

I only see two feasible options here:

1. we remove the profile selection feature for macOS and create a new profile for each PWA installation.
2. we attempt some profile trickery, by which we create a new profile for each PWA but try to symlink common files from the “shared” profile, like add-ons and preferences. I have not tried this, so I don't know if it actually works, but if it works, it still would be quite unreliable as it would be a very unexpected setup for Firefox.

On a side note: I investigated how Chromium is dealing with this issue, and they are launching a tiny process that provides the system integration and imports a framework / library from the main chromium app bundle. This then allows them to create a hidden tab inside the main chromium process, but remotely display it inside the PWA process.

[filips123]

There is a similar processes-related problem on Linux which I also haven't fixed yet. I use --class command argument with a PWA ID when launching Firefox to set WM_CLASS which should separate all PWAs and make them use correct icons. However, when some PWA is already running, all newly launched PWAs will merge with it and remain merged until all PWAs are closed. I think this happens because all Firefox windows, even if launched using multiple commands, will still share the same processes, causing them to have WM_CLASS of the first PWA. I think this Linux problem could be fixed (apart from using separate profiles as you already mentioned) if Firefox would allow privileged JS that runs in Firefox UI to set WM_CLASS for the current window independently of all other windows (similar to setGroupIdForWindow, but this probably requires changing C++ code and recompiling Firefox. If this could work and won't be too hard, I could maybe try doing this sometime in the future, and submit a patch to Firefox.

What happens on macOS when you have multiple PWAs, but only have one running at the time? Will it still work and have the correct icon, and break only when you open multiple PWAs? If so, I think it's fine for the first version of macOS system integration, but should be fixed in the future.

For solutions, I unfortunately don't know what the best thing would be. Separate profiles for each PWA could be quite annoying, as users would have to re-configure everything for each PWA (which can be a lot of work if they use more addons and configurations). Profile trickery would be better for users (except when it breaks) but I agree it would be quite unreliable. Is it possible to do something similar to what Chromium does? Or maybe there is some macOS system API that can change the "ID" of the window (like Windows' AppUserModelIDs or Linux XSetClassHint)? If there is such API, maybe it could be possible to submit another patch to Firefox to allow privileged JS to access it?

I added current limitations section to README and linked it from the wiki. It describes current problems with window handling that I cannot solve yet. If macOS integration works with only one PWA open at the time and only breaks with multiple, please add still create PR and describe the problem in that section. If it always breaks, we will have to do something else...

[TitanNano]

What happens on macOS when you have multiple PWAs, but only have one running at the time? Will it still work and have the correct icon, and break only when you open multiple PWAs? If so, I think it's fine for the first version of macOS system integration, but should be fixed in the future.

Yes, it will work properly for the first PWA. Every PWA which is then launched looks as if it instantly quits and a new window inside the first PWA is opened.

I added current limitations section to README and linked it from the wiki. It describes current problems with window handling that I cannot solve yet. If macOS integration works with only one PWA open at the time and only breaks with multiple, please add still create PR and describe the problem in that section. If it always breaks, we will have to do something else...

Alright, I will do that. I think we can tell people to work around this issue by using a new profile for each PWA. It's then up to the user to choose a trade-off.

[TitanNano]

Is it possible to do something similar to what Chromium does?

Maybe. Gecko uses IPC links internally to render websites in its content processes, but display them in the window of the parent process. Here is a brief explanation from back in 2013 when it was first implemented. I think we might also be able to use the same IPC protocol between our host process and the main Firefox runtime, but there is not much public documentation on how exactly this works. I think we would have to find a gecko engineer who can tell us if a gecko is ready for such a setup or how much work it would be to make it possible.

Or maybe there is some macOS system API that can change the "ID" of the window (like Windows' AppUserModelIDs or Linux XSetClassHint)?

I was not able to find any such API. It also makes sense to me that apple wouldn't want applications to be able to impersonate each other. Here is a short design document from the chromium team that outlines the options they considered when implementing web app into chromium. They also do not mention any such API.

[TitanNano]

Has been implemented in #38

[jackmawer]

There is a similar processes-related problem on Linux which I also haven't fixed yet. I use --class command argument with a PWA ID when launching Firefox to set WM_CLASS which should separate all PWAs and make them use correct icons. However, when some PWA is already running, all newly launched PWAs will merge with it and remain merged until all PWAs are closed. I think this happens because all Firefox windows, even if launched using multiple commands, will still share the same processes, causing them to have WM_CLASS of the first PWA. I think this Linux problem could be fixed (apart from using separate profiles as you already mentioned) if Firefox would allow privileged JS that runs in Firefox UI to set WM_CLASS for the current window independently of all other windows (similar to setGroupIdForWindow, but this probably requires changing C++ code and recompiling Firefox. If this could work and won't be too hard, I could maybe try doing this sometime in the future, and submit a patch to Firefox.

What happens on macOS when you have multiple PWAs, but only have one running at the time? Will it still work and have the correct icon, and break only when you open multiple PWAs? If so, I think it's fine for the first version of macOS system integration, but should be fixed in the future.

For solutions, I unfortunately don't know what the best thing would be. Separate profiles for each PWA could be quite annoying, as users would have to re-configure everything for each PWA (which can be a lot of work if they use more addons and configurations). Profile trickery would be better for users (except when it breaks) but I agree it would be quite unreliable. Is it possible to do something similar to what Chromium does? Or maybe there is some macOS system API that can change the "ID" of the window (like Windows' AppUserModelIDs or Linux XSetClassHint)? If there is such API, maybe it could be possible to submit another patch to Firefox to allow privileged JS to access it?

I added current limitations section to README and linked it from the wiki. It describes current problems with window handling that I cannot solve yet. If macOS integration works with only one PWA open at the time and only breaks with multiple, please add still create PR and describe the problem in that section. If it always breaks, we will have to do something else...

perhaps a new issue should be made for this? this issue is now closed and the problem on linux still persists.

[filips123]

I didn't create a new issue because it is already listed in current limitations section of README and I thought a separate issue wouldn't be needed. However, I can create a new issue (and perhaps also issues for other "current limitations") if you think that would be useful.

[jackmawer]

I didn't create a new issue because it is already listed in current limitations section of README and I thought a separate issue wouldn't be needed. However, I can create a new issue (and perhaps also issues for other "current limitations") if you think that would be useful.

It definitely makes sense to me that a "current limitation" has a related issue, as "current" implies it will be fixed in future, so it must be a "bug" that the limitation exists now. It would also be useful as a discussion platform for working on these limitations.

[filips123]

Sorry for the delay, but I finally made issue #81 that can be used to track this problem.

[nicroe1979]

Yeah