Repository navigation
[Bug]: .deb install on Wayland shows a second, generic dock icon #13975
Description
Activity
Triage
The duplicate icon matches current main, including the
0.0.43-nightly.20260927build. This is the same startup identity bug as #10894, on the.debrather than the AppImage. It should stay open. #10895 is the related fix and is not in this nightly.The
.debinstalls/usr/share/applications/t3code.desktop(executableName: "t3code", nodesktopName) withIcon=t3codeandStartupWMClass=t3code(scripts/build-desktop-artifact.ts). On Linux startup,DesktopPreReadyPlatformstill writes~/.local/share/applications/com.t3tools.T3Code.desktopfromrenderUrlHandlerDesktopEntry(NoDisplay=true, noIcon=, noStartupWMClass) and callssetDesktopName("com.t3tools.T3Code.desktop"). Electron 44.4.2 then uses that name for both the Wayland app id andWM_CLASS. GNOME matchesStartupWMClassfirst, then the desktop-file id.t3codedoes not matchcom.t3tools.T3Code, so the hidden entry wins and the pinned launcher stays separate. That hidden entry is intentional for AppImages, whose launcher filename we do not control (DesktopLinuxUrlHandler); it was left withoutStartupWMClassso it would not take the window. It takes the window anyway because the packaged launcher was never updated to the idsetDesktopNameactually sets.X11 is unaffectedis not a safe assumption here. Electron 44 setsWM_CLASSfrom the desktop name (electron/electron#51424), and--class t3codedoes not put the main window back ont3code. #10894 already has an X11 trace ofWM_CLASS = "com.t3tools.t3code", "com.t3tools.T3Code". The second dock entry is the GNOME Wayland symptom; the identity mismatch is the same on X11.Two fixes, and they conflict:
- Prefer the fix(desktop): Group Linux windows under the installed launcher #10895 direction. Keep the window id at
com.t3tools.T3Codeand set the installed launcher'sStartupWMClasstocom.t3tools.T3Code(electron-builder entry and the AURt3code.desktopfiles). GNOME then groups the window under the pinnedt3code.desktop. Capture bindings stay oncom.t3tools.T3Code. AddingIcon=t3codeto the hidden handler only fixes a generic glyph; it does not remove the second dock entry. - The packaged non-AppImage switch to
t3code.desktopis the other coherent fix, but it is larger than the four bullets.linuxDesktopEntryNameis also the capture app id inDesktopSnapShot(portal, niri, hyprland), and the GNOME extension only authorizescom.t3tools.T3Code.SnapShot. ChangingsetDesktopNamewithout those call sites desyncs window capture. The hidden entry is written twice (pre-ready, thenDesktopLinuxUrlHandler), andxdg-mime defaultis pointed atcom.t3tools.T3Code.desktopon every packaged launch. A.debbuild would also need to retarget that, and existingmimeapps.listentries keep pointing at the old handler until then. AppImage and dev (com.t3tools.T3Code.Development.desktop) still need the hidden handler. This also fights fix(desktop): Group Linux windows under the installed launcher #10895, which movesStartupWMClassthe other way. Landing both would break the association again.
A PR is welcome if it keeps one Linux window id. I would not special-case
.debtot3codeunless we also move capture and the scheme handler with it.- Prefer the fix(desktop): Group Linux windows under the installed launcher #10895 direction. Keep the window id at
Confirmed that the existing AppImage PR fixes the .deb too so i won't make a conflicting PR! :)
Before submitting
Area
apps/desktop
Steps to reproduce
T3-Code-<version>-amd64.debon a Wayland session.Expected behavior
The running window is grouped under the pinned T3 Code launcher.
Actual behavior
A second dock entry with a generic cog icon appears next to the pinned launcher.
The package installs
/usr/share/applications/t3code.desktopwithIcon=t3codeandStartupWMClass=t3code. At startup the app still callssetDesktopName("com.t3tools.T3Code.desktop")(DesktopPreReadyPlatform.ts) and writes a hidden handler entry to~/.local/share/applicationswithNoDisplay=trueand noIcon=. On Wayland the compositor matches the window by its app id, so it picks that hidden entry over the installed launcher. X11 is unaffected because it matches onWM_CLASS.Impact
Cosmetic issue
Version or commit
0.0.43-nightly.20260927.2344 (.deb)
Environment
Ubuntu 26.04.1 LTS, GNOME Shell 50.1, Wayland
Related
#10894 has the same
setDesktopNameroot cause on the AppImage. The fix is different here: the.debinstalls a real launcher the app can use, while the AppImage has none.Possible fix
For packaged installs that aren't an AppImage (
app.isPackaged && !process.env.APPIMAGE), leaving the AppImage and dev paths as they are:t3code.desktop, so the app id matches the installed launcher.desktopalready registersx-scheme-handler/t3codexdg-mime defaultatt3code.desktopt3codeapp id inDesktopSnapShotwindow matchingI've been shipping this in a fork's
.debbuilds and can open a PR if it's wanted.