Chromium-based browsers icons are not swallowed on stalonetray restart.
Closed this issue · 5 comments
I restart stalonetray (flipping -v option) when changing orientation of my screen (portrait/landscape). All tray icons get swalloved again, but chromium-based browsers (google-chrome, brave, chromium, ...) do not. (They disappear or appear on some random location on screen.)
This may be related to https://bugs.chromium.org/p/chromium/issues/detail?id=1042098 . (I cannot say if stalonetray has this wrong, I post this issue, so that the problem can be tracked.)
Thanks for the report and the #5. I will provide some feedback on the PR later. Meanwhile, is it possible to record the logs of the disappearance and, also, the log of the stalonetray starting without the workaround applied (I wonder if it sees the runaway icons).
It does not disappear from stalonetray. It disappears when stalonetray is restarted, i.e., it never appears in stalonetray when it is started after the chromium-based browsers. Here I attach trace of first stalonetray run (where brave-browser and chromium are launched while stalonetray is running). Second run (ctrl-c and re-launch stalonetray, while the two browsers are running). And for completeness there is log of what my patch does. I also attach output of xprop on the two icons, when they are not inside stalonetray. (Chromium does not destroy its icon when stalonetray is ended, the icon just jumps to some other place on the screen.)
first-run.log
second-run.log
patched-second-run.log
brave-props.txt
chromium-props.txt
p.s.: chromium-based browsers shows their icon only when they have some process that should stay alive when all windows are closed. For me it is pagerduty-notifier plugin. My windowmanager is notion, but I guess it does not interfere with tray icons in any way.
Can you please dump xprops of the root window during the first run, between the first and second run, and during the second run? The browsers should be tracking the system tray selection and react if it changes. I think it is bug in the apps, but this does not mean we cannot work around it. I just want to understand the situation better.
Edit: I've just looked at ui/platform_window/x11/x11_window.cc, and I could not find where they track selection changes. The behavior suggests that they don't, but I cannot prove it looking at the code.
Do you mean xprop -root ? All that changes there is _NET_ACTIVE_WINDOW(WINDOW). This is output of my xprop -root for all runs (except the active window property):
InterpRegistry(STRING) = "7400001 gitk"
AT_SPI_BUS(STRING) = "unix:abstract=/tmp/dbus-vtXAtxXODY,guid=<censored>"
CUT_BUFFER0(STRING) = "<censored>"
VimRegistry(STRING) = "1600007 GVIM2", "8600007 GVIM1", "8800007 GVIM3", "8a00007 GVIEW", "800007 GVIEW1", "9400007 GVIM6", "8200007 GVIM", "8400007 GVIM4", "8e00007 GVIEW4", "7800007 GVIEW3", "1000007 GVIEW2"
_ION_WORKSPACE2(STRING) = "WGroupWS<2>"
_ION_WORKSPACE1(STRING) = "WGroupWS<1>"
GDK_VISUALS(INTEGER) = 314, 413
_NET_ACTIVE_WINDOW(WINDOW): window id # 0x240000e
_ION_WORKSPACE(STRING) = "WGroupWS"
_NET_VIRTUAL_ROOTS(WINDOW): window id # 0x400015, 0x400026, 0x400027
_NET_SUPPORTED(ATOM) = _NET_WM_NAME, _NET_WM_STATE, _NET_WM_STATE_FULLSCREEN, _NET_WM_STATE_DEMANDS_ATTENTION, _NET_SUPPORTING_WM_CHECK, _NET_VIRTUAL_ROOTS, _NET_ACTIVE_WINDOW, _NET_WM_ALLOWED_ACTIONS, _NET_WM_MOVERESIZE
_NET_SUPPORTING_WM_CHECK(WINDOW): window id # 0x400013
XFree86_DDC_EDID1_RAWDATA(INTEGER) = 0, -1, -1, -1, -1, -1, -1, 0, 9, -27, -84, 6, 0, 0, 0, 0, 3, 25, 1, 4, -107, 31, 17, 120, 2, -99, 64, -102, 93, 85, -115, 40, 30, 80, 84, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, -68, 57, -128, 24, 113, 56, 40, 64, 48, 32, 53, 0, 53, -83, 16, 0, 0, 26, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 26, 0, 0, 0, -2, 0, 66, 79, 69, 32, 68, 84, 10, 32, 32, 32, 32, 32, 32, 0, 0, 0, -2, 0, 78, 86, 49, 52, 48, 70, 72, 77, 45, 78, 52, 53, 10, 0, -73
RESOURCE_MANAGER(STRING) = "*.vt100.bellIsUrgent:\ttrue\n*.vt100.utf8Title:\ttrue\n*.vt100.visualBell:\ttrue\n*.vt100.visualBellDelay:\t20\n*customization:\t-color\nXkbLEDPanel.xkbleds.*.BottomColor:\t#444444\nXkbLEDPanel.xkbleds.*.LedHeight:\t16\nXkbLEDPanel.xkbleds.*.LedWidth:\t7\nXkbLEDPanel.xkbleds.*.TopColor:\tblack\nXkbLEDPanel.xkbleds.background:\t#222222\nXkbLEDPanel.xkbleds.borderWidth:\t0\nXkbLEDPanel.xkbleds.hSpace:\t1\nXkbLEDPanel.xkbleds.led1.OffColor:\t#003300\nXkbLEDPanel.xkbleds.led1.OnColor:\t#33FF33\nXkbLEDPanel.xkbleds.led13.OffColor:\t#222200\nXkbLEDPanel.xkbleds.led13.OnColor:\t#EEEE00\nXkbLEDPanel.xkbleds.led2.OffColor:\t#000066\nXkbLEDPanel.xkbleds.led2.OnColor:\t#4444FF\nXkbLEDPanel.xkbleds.led3.OffColor:\t#440000\nXkbLEDPanel.xkbleds.led3.OnColor:\t#FF2222\nXkbLEDPanel.xkbleds.orientation:\tXtorientVertical\nXkbLEDPanel.xkbleds.vSpace:\t4\nXpdf*fileFilterStyle:\tfilter_hidden_files\nfookb.command:\t/usr/bin/play /usr/share/fookb/beep_spring.au\nfookb.icon1:\t/usr/share/fookb/1.xpm\nfookb.icon2:\t/usr/share/fookb/2.xpm\nfookb.icon3:\t/usr/share/fookb/3.xpm\nfookb.icon4:\t/usr/share/fookb/4.xpm\nfookb.iconBoom:\t/usr/share/fookb/boom.xpm\nfookb.sound:\tNo\nxdvi.Offset:\t0,0\nxdvi.expertMode:\t3\nxdvi.mainTranslations:\t#override Ctrl<Key>[:back-page()\\nCtrl<Key>]:forward-page()\\n\nxdvi.shrinkFactor:\t5\nxdvi.watchFile:\t1\nxterm*decTerminalID:\t340\nxterm*faceName:\tFira Code Bold\nxterm*faceSize:\t7\nxterm*font:\t-gnu-unifont-*-*-*-*-*-*-100-100-*-*-iso10646-1\nxterm*numColorRegisters:\t256\nxterm*renderFont:\tfalse\n"
_XKB_RULES_NAMES(STRING) = "evdev", "pc105", "us+cz:2+group(switch)+group(shifts_toggle)", "", ""
XFree86_has_VT(INTEGER) = 1
XFree86_VT(INTEGER) = 1
P.S: xprop -root -spy also does not reveal any other changing property
Thanks. Closing as a workaround has been merged.