All PWAs in the same profile are merged with the first PWA that was opened (Linux Wayland-only)

[filips123]

Description

All PWAs are merged with the first PWA that was opened. This only applies to Linux.

When some PWA is already running, all newly launched PWAs will merge with it and remain merged until all of them are closed. This will cause the app menu to display all PWAs as part of the first PWA that was launched, with its icon and desktop actions (if any).

Users can prevent this by installing each PWA into a different profile.

Steps to Reproduce

1. Install at least two different PWAs into the same profile.
2. Launch the first PWA.
3. See that it has the correct icon.
4. Launch another PWA without closing the first one.
5. See that is merged with the first one and has the wrong icon.

Possible Solution

This cannot be fixed easily. The native part of the project currently launches Firefox with the --class argument, which should set the WM_CLASS property of the window to the PWA ID. However, because all Firefox processes in the same profile are connected together, all windows have WM_CLASS of the first PWA. Fixing this would probably require modifying Firefox C++ code. Check this comment and related discussions for ideas and possible solutions to fix this.

[alchzh]

xprop can externally set the WM_CLASS of the window after it was created w/o modifying the Firefox binary itself. idk what this will do if you have wayland though.

[filips123]

Is it possible to programmatically select the correct Firefox window and then set its WM_CLASS? But then we will still need something similar for Wayland...

Well, maybe the best solution is to report a bug/suggestion to Firefox that --class argument should be respected for each window that is opened, even if they are in the same profile (or to implement another way to make sure windows are not grouped).

[filips123]

I created a bug on Bugzilla. Feel free to upvote or comment if you have any useful info, but please don't spam it with unnecessary comments.

[Coeur-Noir]

Hi,

Have a different firefox profile for each PWA ?

That's how I do it manually, the --class / WMCLASS is relative to one profile.
This way some websites have their own icon in OS interface ( icon tasks list, or dock ) detached from the « main » Firefox.

You may eventually synchronize all these PWA profiles with your personal mozilla account ( ie. synchronize only passwords and history. )

You may look at https://github.com/linuxmint/webapp-manager which also aims at PWA.

Be aware also that native host messaging is not yet implemented in snap and flatpak ( Linux ) packaging.
So for the moment Ubuntu 22.04 users with Firefox as a snap by default won't be able to try your work.

[filips123]

Have a different firefox profile for each PWA ?

A different PWA Firefox profile for each PWA (PWAsForFirefox uses a separate profile system but in the end result is the same).

When installing a PWA, you need to create a new profile and assign PWA to it:

[Coeur-Noir]

Hi,

This is how it works for me « manually » ie. not « true » PWA.

Regular Firefox has its legacy launcher :

firefox.desktop

[Desktop Entry]
Version=1.0
Name=Firefox Web Browser
Name[fr]=Navigateur Web Firefox
Comment=Browse the World Wide Web
Comment[fr]=Naviguer sur le Web
GenericName=Web Browser
GenericName[fr]=Navigateur Web
Keywords=Internet;WWW;Browser;Web;Explorer
Keywords[fr]=Internet;WWW;Browser;Web;Explorer;Fureteur;Surfer;Navigateur
Exec=firefox %u
Terminal=false
X-MultipleArgs=false
Type=Application
Icon=firefox
Categories=GNOME;GTK;Network;WebBrowser;
MimeType=text/html;text/xml;application/xhtml+xml;application/xml;application/rss+xml;application/rdf+xml;image/gif;image/jpeg;image/png;x-scheme-handler/http;x-scheme-handler/https;x-scheme-handler/ftp;x-scheme-handler/chrome;video/webm;application/x-xpinstall;
StartupNotify=true
Actions=new-window;new-private-window;

[Desktop Action new-window]
Name=Open a New Window
Name[fr]=Ouvrir une nouvelle fenêtre
Exec=firefox -new-window

[Desktop Action new-private-window]
Name=Open a New Private Window
Name[fr]=Ouvrir une nouvelle fenêtre de navigation privée
Exec=firefox -private-window

Deezer has its own :

deezer.desktop

[Desktop Entry]
Version=1.1
Type=Application
Name=Deezer
Comment=Deezer via Firefox
Icon=deezer
Exec=firefox --new-window -P Deezer https://www.deezer.com/fr/ --class Deezer %u
Actions=
Categories=AudioVideo;Audio;Player;Network;
StartupWMClass=Deezer
StartupNotify=true

and Google Drive another one :

google-drive.desktop

[Desktop Entry]
Version=1.1
Type=Application
Name=Google Drive
Comment=Google Drive via Firefox
Icon=google-drive
Exec=firefox --new-window -P Gdrive https://drive.google.com/drive/my-drive --class Gdrive %u
Actions=
Categories=Network;
StartupWMClass=Gdrive
StartupNotify=true

Firefox profile contains :

django@ASGARD:~$ ls -la .mozilla/firefox/
total 44
drwx------  9 django django 4096 juin  20 22:21  .
drwx------  5 django django 4096 juin  10 03:30  ..
drwx------  3 django django 4096 juin   9 17:04 'Crash Reports'
drwxrwx--- 13 django django 4096 juin  20 22:20  dj4ng0.Deezer
drwxrwx--- 10 django django 4096 juin  20 22:12  dj4ng0.Gdrive
drwx------ 10 django django 4096 juin   1 19:37  e31kfxht.default-release
drwx------  2 django django 4096 juin  20 22:21  firefox-mpris
drwx------ 14 django django 4096 juin  20 22:21  g3r47d.default
-rw-rw-r--  1 django django  125 juin   1 19:42  installs.ini
drwx------  2 django django 4096 juin   1 19:35 'Pending Pings'
-rw-rw-r--  1 django django  417 juin  20 21:38  profiles.ini
django@ASGARD:~$ 

and profiles.ini contains :

[Profile3]
Name=Gdrive
IsRelative=1
Path=dj4ng0.Gdrive          # part after the dot same as name

[Profile2]
Name=Deezer
IsRelative=1
Path=dj4ng0.Deezer

[Profile1]
Name=default
IsRelative=1
Path=g3r47d.default

[Profile0]
Name=default-release
IsRelative=1
Path=e31kfxht.default-release

[InstallFF3DB405C1B59D61]
Default=e31kfxht.default-release
Locked=1

[General]
StartWithLastProfile=1
Version=2

[Install6AFDA46A1A8AD48]
Default=g3r47d.default
Locked=1

In launchers, mind the Exec and StartupWMClass entries :

• --new-window
• -P
• --class
• %u ( not sure if it's mandatory )

In profiles.ini, mind the naming of each Firefox profile, the same wording for each matters.

If placed into ~/.local/share/applications the desktop files make those websites appear in the « app menu » as « regular » app's.

All these give me for years visually « separate » instances of Firefox for some websites I prefer to keep aside the main Firefox.

Ubuntu here, can't say about Windows nor Mac, sorry.

[silpol]

Is it possible to programmatically select the correct Firefox window

not sure what do you mean by that - in context of which code you say 'select'?

and then set its WM_CLASS?

as you were hinted above, xprop code is good candidate how to manipulate WM_CLASS , i.e. how to get and how to set

you may take a look for :

• man 1 xprop
• xprop source code (gitlab-based)
• quick note about how to use xprop to get WMCLASS from CLI

But then we will still need something similar for Wayland...

sorry, but why?

[silpol]

on general level, I'm not sure whether use of Firefox profiles is wise.

E.g. in my personal case, I use Firefox profiles as namespace, i.e. I have separate entities which help me to be in certain context, i.e. personal or one of numerous but particular work (or non-personal) contexts. So there is me (personal profile), work (my tiny company), work for 1 (main client 1), community (my participation in certain community). This way at least different main credential web login (or few) kept intact.

to project into more clear case for you, I may have created PWA links to Google Meet windows, but in one window it will use my personal Gmail account, and all others it will use respective Google Workspace identity per each other profile.

in this context, asking me to create separate profile on each PWA window might be too much. it might be wiser to add in your firefox add-on simple function - besides creation of new profile each time (if you do need it, as you see, I don't), I could re-use existing profiles of Firefox, so I just select existing ones.

[filips123]

not sure what do you mean by that - in context of which code you say 'select'?

After a web app is launched, the code (which launches Firefox runtime here) needs to detect which window has just been opened so it can apply the new WM_CLASS to it.

sorry, but why?

I'm not sure if xprop works properly on Wayland.

on general level, I'm not sure whether use of Firefox profiles is wise.

PWAs will always have to use a different profile system than the main due to how required Firefox modifications are allowed. However, you can still use the same PWA profile on multiple PWAs and replicate your profiles setup for PWAs. When you install a new PWA, just select an existing profile instead of the option to create a new one. The reason that the separate profile for each PWA is default is that because of this issue when you opened multiple PWAs from the same profile at the same time, all of them get merged together in the taskbar.

[airbreather]

Per the latest comment on bugzilla, I have installed Firefox 112.0 in Arch. I am able to have multiple separate web apps using the same profile without any obvious issues.

As I (mostly coincidentally) just tried this out for the first time today, I'm not 100% sure what I would have expected to have seen prior to 112.0, but I am currently running separate Google pages as their own separate web apps, and I only had to log in on one of them.

So perhaps this issue can be changed to "update the messaging (and perhaps the default selection) in the browser extension"?

[filips123]

Yes, this issue should have been fixed since PWAsForFirefox 2.5.0 and Firefox 112.0. I've waited before updating the warning in the extension until Firefox 112.0 is released, so I'll update it in the next release.

But I've discovered another problem on Linux when multiple web apps are installed to the same profile and opened together. When changing the titlebar color is enabled, the text and window control colors are changed based on color to provide contrast. However, when multiple web apps are opened and they have different colors (for example, one light and another dark), window control colors in all windows are changed to the same color, so window controls in one window become less visible or even invisible.

I don't think there is an easy way to fix this, so I'll open a new issue for this soon. Then, I'll have to decide whether it's better to disable titlebar color changing on Linux by default and change the profile selection in the extension, or to keep the theme color changing enabled and installation in new profiles selected by default but just update the warning message.

[filips123]

I created #322 for that new issue about window control colors. For now, I decided just to change the warning message and keep the default selection in the extension the same.

[xplosionmind]

Hi! This bug appears to be fixed, but the warning when creating a new PWA still appears. Should we still follow the warning, or the writing should be removed as the bug is fixed?

Thanks a lot, @filips123!

[filips123]

The original problem (merging multiple web apps) has been fixed and the fix has already been released. The warning message has also been updated but this change hasn't been released yet.

However, there is another problem that affects when there are multiple web apps in the same profile (#322). It's a smaller problem and has a workaround (disable "Allow web apps to override a theme (titlebar) color" in the app browser settings). If you do this workaround, it should be fine to install multiple web apps to the same profile.

[filips123]

#81 (comment)

I tested this again, and it appears this issue is still not fixed on Wayland with the MOZ_ENABLE_WAYLAND environment variable (or option "use Wayland Display Server in the extension settings) enabled. It also doesn't work when launching directly from the extension, because then PWAs are still launched in full Wayland mode. However, it works fine in Xwayland mode. I don't remember if I tested full Wayland support back then when I created this fix, so I don't know if this is caused by some recent change in Firefox or GNOME/Wayland or if it has always been like that.

The original fix is implemented in Firefox by using XSetClassHint to set res_name and res_class to FFPWA-ID for each window. The problem is probably that XSetClassHint does not work under Wayland, so we need another way to set a separate "ID" for each window. I've found that gtk added gdk_wayland_window_set_application_id, which is apparently used in LibreOffice for a similar thing, but I don't know if can work with Firefox.

I might try to use gdk_wayland_window_set_application_id to set the correct ID and submit a patch to Firefox if it works, but I don't know yet when I'll have time (I'm currently working on rewriting some parts of the project, and some other things). Of course, if anyone else can do this, I would appreciate this!

@julian-klode I'm continuing the discussion here because this is the relevant issue for Linux.

[julian-klode]

Oh thanks, sorry about the comment in the wrong bug, I didn't see a Linux issue, didn't expect it to be closed I guess :)

[filips123]

I submitted a patch to Firefox that should also fix this issue on Wayland.

[filips123]

The patch has been merged and should be available in Firefox 120 (released on 2023-11-21).