Comments (12)
@filips123 I still have to do some clean up, but it looks promising so far.
from pwasforfirefox.
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!
from pwasforfirefox.
@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:
- we remove the profile selection feature for macOS and create a new profile for each PWA installation.
- 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.
from pwasforfirefox.
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...
from pwasforfirefox.
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.
from pwasforfirefox.
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.
from pwasforfirefox.
Has been implemented in #38
from pwasforfirefox.
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 setWM_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 haveWM_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 setWM_CLASS
for the current window independently of all other windows (similar tosetGroupIdForWindow
, 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.
from pwasforfirefox.
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.
from pwasforfirefox.
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.
from pwasforfirefox.
Sorry for the delay, but I finally made issue #81 that can be used to track this problem.
from pwasforfirefox.
Yeah
from pwasforfirefox.
Related Issues (20)
- Linux aarch64 Support for Runtime installer? HOT 2
- Error: "can't access property "href", e is null" HOT 2
- Allow user to edit the name of the PWA when installing HOT 5
- Changing the default links target option HOT 4
- Winget option not working properly. HOT 7
- Fix launching without `JOB_OBJECT_LIMIT_BREAKAWAY_OK` permission HOT 8
- How do I use these environment variables? HOT 1
- Add an option to open app to previous state HOT 2
- Closing Firefox causes PWA to crash HOT 7
- All PWA windows open as a Blank window HOT 7
- Failed to uninstall firefoxpwa runtime HOT 2
- CORS whitelist option HOT 2
- Corners are not rounded, inner site overlaps. HOT 4
- Scrolling at lower FPS on 120hz Screen. macOS Sonoma. HOT 1
- Web apps broken in Firefox 124 HOT 19
- Can't pin PWA apps to taskbar after update HOT 2
- False positive malware detection by Microsoft Defender HOT 3
- Crunchyroll doesn't work with manifest enabled HOT 3
- macOS task switchers always show the Firefox icon HOT 2
- Allowed Domains: Support Wildcard/Regex HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pwasforfirefox.