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

Question

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

grahamperrin opened this issue 4 years ago · comments

Graham Perrin commented 4 years ago

2021-01-24.10.35.mp4

probonopd · Answer 1 · Sun Jan 24 2021 18:48:44 GMT+0800 (China Standard Time)

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

Graham Perrin · Answer 2 · Sun Jan 24 2021 19:08:39 GMT+0800 (China Standard Time)

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 · Answer 3 · Sun Jan 24 2021 19:16:11 GMT+0800 (China Standard Time)

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?

Graham Perrin · Answer 4 · Sun Jan 24 2021 20:15:11 GMT+0800 (China Standard Time)

I never noticed blueness, I see black.

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

probonopd · Answer 5 · Sun Jan 24 2021 20:27:30 GMT+0800 (China Standard Time)

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

probonopd · Answer 6 · Fri Mar 12 2021 01:46:57 GMT+0800 (China Standard Time)

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 · Answer 7 · Thu Apr 01 2021 14:22:45 GMT+0800 (China Standard Time)

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 :~) · Answer 8 · Mon May 24 2021 17:02:29 GMT+0800 (China Standard Time)

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 · Answer 9 · Wed May 26 2021 02:27:02 GMT+0800 (China Standard Time)

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 :~) · Answer 10 · Wed May 26 2021 06:04:37 GMT+0800 (China Standard Time)

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 · Answer 11 · Fri May 28 2021 02:18:55 GMT+0800 (China Standard Time)

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 :~) · Answer 12 · Fri May 28 2021 04:42:20 GMT+0800 (China Standard Time)

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

Kettle :~) · Answer 13 · Fri May 28 2021 06:11:46 GMT+0800 (China Standard Time)

I'll see if removing the desktop file works.

probonopd · Answer 14 · Sat May 29 2021 02:56:19 GMT+0800 (China Standard Time)

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 :~) · Answer 15 · Sat May 29 2021 04:44:53 GMT+0800 (China Standard Time)

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