Mozilla Firefox pinned to the dock, but not launching in response to a click on the icon

[grahamperrin]

2021-01-24.10.35.mp4

[probonopd]

Let's revisit this once we have Firefox as a (wrapper) .app bundle...

[grahamperrin]

Thanks.

In the meantime, if it helps … in this frame from the screen recording, there was very faint hint of a circular 'running' indicator beneath the icon, some time after using QTerminal to run firefox:

[probonopd]

very faint hint of a circular 'running' indicator beneath the icon

Do you mean the blue dot? It is for the frontmost application. I guess we should make it white?

[grahamperrin]

I never noticed blueness, I see black.

White might be better against the default desktop background but I wonder about other contexts.

[probonopd]

Will set to white for now. At least the defaults need to work well together ;-)

[probonopd]

Firefox (when installed by pkg and not having an .app bundle nor an .AppDir) cannot be launched when pinned to the Dock because the Dock cannot figure out the corresponding .desktop file.

• /usr/share/applications is hardcoded in systemappmonitor.c as the location that is searched for .desktop files (this does not exist on FreeBSD; QStandardPaths::ApplicationsLocation should be used instead)
• xWindowWMClassName is used in utils.cpp to find "matching" desktop files; xWindowWMClassName of Firefox is Navigator
• utils.cpp tries to match Navigator to
  • The name of desktop files (e.g., Navigator.desktop - no such file exists)
  • StartupWMClass in the desktop files (e.g., StartupWMClass=Navigator - no such key exists)
  • Icon in the desktop files (e.g., Icon=Navigator.png - this does not match)
  • Exec in the desktop files (e.g., Exec=Navigator - this does not match)

As a quick and dirty workaround I will change the hardcoded /usr/share/applications to /usr/local/share/applications for FreeBSD; if you add StartupWMClass=Navigator to /usr/local/share/applications/firefox.desktop then you should be able to pin Firefox.

Even with these quick and dirty workarounds utils.cpp does not really find the "matching" desktop files for many applications. This issue should be resolved "properly" in upstream cyber-dock (#19, #20).

This is one example for why we don't like XDG .desktop files and are using .app bundles and .AppDir as our native application formats in helloSystem.

[probonopd]

Work has been done in Filer since this had been reported, however this might also be an issue with firefox.desktop missing a StartupWMClass entry which might have to be fixed in FreeBSD Ports. But then, because the desktop file is called firefox.desktop it should also match heuristically. Something is still wrong. Need to check with upstream again.

xprop shows WM_CLASS(STRING) = "Navigator", "Firefox".

[kettle-7]

I made a Firefox wrapper app bundle (and Thunderbird) and neither works from the dock.

I might be able to make a "real" bundle, with CMake and Meson it's piece of cake.

[probonopd]

Neither works from the dock.

Please describe what the issue is. If the Dock doesn't show the icon of an app bundle correctly, then possibly there is a bug in the Dock.

[kettle-7]

The issue is associating Firefox's wm class with its app bundle. If you pin it, close it, then try and launch it from the dock nothing happens.

[probonopd]

FreeBSD% launch "Firefox Web Browser"
# Found "/Applications/Firefox Web Browser.app/Firefox Web Browser"

Launches Firefox and shows the correct icon for me. Can you confirm?

But the issue starts thereafter: if you right-click on the icon, it says "Keep Mozilla Firefox in Dock" instead of "Keep Firefox Web Browser in Dock", and if you choose it, then

FreeBSD% cat ~/.config/cyberos/dock_pinned.conf 
(...)
[Firefox]
DesktopPath=
Exec=
IconName=firefox
Index=5
visibleName=Mozilla Firefox
(...)

This is clearly wrong. We should get something like

[Firefox%20Web%20Browser]
DesktopPath=
Exec=/Applications/Firefox Web Browser.app/Firefox Web Browser
IconName=file:///Applications/Firefox Web Browser.app/Resources/Firefox Web Browser.png
Index=1
visibleName=Firefox Web Browser

So here, the bug is likely that ithe Dock gets confused between the Firefox installed in the system (.desktop file) and the /Applications/Firefox Web Browser.app/.

Hence, this is probably a bug in Dock.

[kettle-7]

Right. So for now, I can edit that file.

[kettle-7]

I'll see if removing the desktop file works.

[probonopd]

In the example below, the issue is that the window that gets rendered on the screen is from process ID 2164 rather than 2162. Dock tries to look up process ID 2164 to see whether it is in an AppDir or .app bundle, but it isn't (2162 is).
Hence we need to find a way to

• Find out whether a process outside of an .AppDir or .app bundle was launched by and belongs to an .AppDir or .app bundle, or
• Attach to launched processes and to their sub-processes the information that they were launched by an .AppDir or .app bundle. For example, process 2161 could export an environment variable like APP_BUNDLE=/Applications/Firefox Web Browser.app which then would get propagated to all of its child processes

2161  -  I     0:00,05 /usr/local/bin/launch /Applications/Firefox Web Browser.app
2162  -  I     0:00,12 python3 /Applications/Firefox Web Browser.app/Firefox Web Browser (python3.7)
2163  -  I     0:00,05 launch /usr/local/lib/firefox/firefox
2164  -  S     0:03,31 /usr/local/lib/firefox/firefox
2166  -  S     0:01,52 /usr/local/lib/firefox/firefox -contentproc -childID 1 -isForBrowser -prefsLen 1 -prefMapSize 232414 -parentBuildID 20210401095825 -appdir /usr/local/lib/firefox/browser 2164 tab
2169  -  S     0:00,62 /usr/local/lib/firefox/firefox -contentproc -childID 2 -isForBrowser -prefsLen 6190 -prefMapSize 232414 -parentBuildID 20210401095825 -appdir /usr/local/lib/firefox/browser 2164 tab
2170  -  S     0:00,32 /usr/local/lib/firefox/firefox -contentproc -childID 3 -isForBrowser -prefsLen 7049 -prefMapSize 232414 -parentBuildID 20210401095825 -appdir /usr/local/lib/firefox/browser 2164 tab

[kettle-7]

Good idea, but if say Firefox was to launch /usr/local/bin/filer-qt as a subprocess...

I wonder if anyone has seen the same issue in AppImage with the ld library path variable...