Synology-Drive Icon is not correctly positioned

[nicolas-rdgs]

Describe the issue

I'm on Archlinux and I have installed the package "synology-drive" from AUR (https://aur.archlinux.org/packages/synology-drive/). When I started the application, the icon did not have been correctly placed on the bar. In fact, the icon floating to the left whereas my systray is positioned to the right.

Expected behavior:

The icon of this app must be placed in systray block with the correct size.

Actual behavior:

the regular icons are well placed in systray emplacement but the icon of synology-drive floating to the left.

Was it working before?
All working fine excepting that.

To Reproduce

Install synology-drive and launch the application.

# Polybar tray config
[bar/top]
...
tray-position = right
tray-padding = 4
tray-maxsize = 16
;tray-transparent = true
;tray-detached = true
;tray-offset-x = 50
...

Polybar Log

No log line was written during the test.

Screenshots

https://imgur.com/KEo6G4D

Environment:

• WM: i3wm
• Output of polybar -vvv:

polybar 3.2.1

Features: +alsa +curl +i3 -mpd +network +pulseaudio +xkeyboard

X extensions: +randr (+monitors) -render -damage -sync -composite +xkb +xrm +xcursor

Build type: RelWithDebInfo
Compiler: /usr/bin/c++
Compiler flags: -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -Wall -Wextra -Werror -Wno-noexcept-type -O2 -pedantic -pedantic-errors
Linker flags: -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now

[tramhao]

I have the same issue here. I'm on manjaro.
polybar 3.3.0-1
synology-drive 1.1.4-10580
bspwm-manjaro 0.9.7-3

[patrick96]

This looks very similar to #545

There the issue was that the tray icon was not actually attached to polybar.

A few questions:

1. If you put your bar at the bottom (bottom = true), is the synology tray icon still on the top left of the screen?
2. Does this icon also appear when polybar is not running?

[tramhao]

For me

1. Bottom = true, synology tray icon is still on the top left.
2. killall polybar, then this icon disappear.

[patrick96]

Was able to reproduce this now. It doesn't happen with stalonetray, so this seems like a polybar bug.

[nicolas-rdgs]

Just for confirmation too, I have the same behavior as tramhao with 'bottom = true'.
Have you able to find the root cause?

[mwip]

If this helps at all, I also experience this weird behavior with qtile. Before I ran KDE, there it happend as well.
In both cases helped to delay the autostart using e.g. sleep 60 && synology-drive & in your autostart script.

[tdehaeze]

This does not change anything for me.

[moonwitch]

This still occurs, is there any way we could assist in fixing this?

[patrick96]

@moonwitch I think the greatest help here would be to dig into the code, run polybar under gdb and figure out where things go wrong compared to other well-behaving tray icons. From there it should be easier to figure out why this happens for this particular icon and not others.

[moonwitch]

Alright. Never done that before, but this is an excellent reason and method to learn. Will try my best. Sent while on the road, errors may occur.

…

On Thu, Jan 23, 2020, 23:55 Patrick Ziegler ***@***.***> wrote: @moonwitch <https://github.com/moonwitch> I think the greatest help here would be to dig into the code, run polybar under gdb and figure out where things go wrong compared to other well-behaving tray icons. From there it should be easier to figure out why this happens for this particular icon and not others. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1679?email_source=notifications&email_token=AAADVV634O2IM576WMNYMBLQ7IN6XA5CNFSM4G4HE5IKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJZE3BY#issuecomment-577916295>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAADVV5ID2OCLAD7KVTT6WDQ7IN6XANCNFSM4G4HE5IA> .

[moonwitch]

Ok; I have no idea if I am doing this right.

Here's what I did:
gdb -ex run -args /usr/bin/polybar topbar -l trace

Since the trace only mentions hexadecimal info; I needed to know which mention was which. So I launched Cloud Drive; but the info I got from xprop isn't found in the polybar trace.

XdndAware(ATOM) = BITMAP
_NET_WM_NAME(UTF8_STRING) = "cloud-drive-ui"
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x1, 0x0, 0x0, 0x0
_NET_WM_WINDOW_TYPE(ATOM) = _KDE_NET_WM_WINDOW_TYPE_OVERRIDE, _NET_WM_WINDOW_TYPE_NORMAL
_XEMBED_INFO(_XEMBED_INFO) = 0x0, 0x1
WM_CLIENT_LEADER(WINDOW): window id # 0x3800002
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: True
		Initial state is Normal State.
_NET_WM_PID(CARDINAL) = 27838
WM_CLASS(STRING) = "cloud-drive-ui", "cloud-drive-ui"
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		user specified location: 6, 4
		user specified size: 16 by 16
		program specified minimum size: 22 by 22
		window gravity: Static

The odd thing is; if I relaunch it all; I actually do spot ONE big difference. This is xprop on relaunch:

WM_NORMAL_HINTS(WM_SIZE_HINTS):
		user specified location: 0, 0
		user specified size: 22 by 22
		program specified minimum size: 22 by 22
		window gravity: Static

Note the 'User specified location'.
This changes, and the location changes a little. How can I trace where that comes from? It seems related, but isn't managed by Polybar.

[moonwitch]

I've tried for a few hours to get the user specified location (which I am now certain of is the cause) to change. I fear it's coded into cloud-drive-ui, not a Polybar issue as Polybar repects the WM_SIZE_HINTS.

[patrick96]

@moonwitch Thanks a lot for digging deeper here. I don't think polybar ever reads any position information from the tray icon, it is the one that sets it.
But in this case I have noticed that polybar doesn't set it. It also doesn't make the tray icon its child window as it does with all other tray icons.

When adding the cloud-drive-ui tray icon, polybar doesn't get further than calling change_window_attributes_checked. There an exception is thrown which is swallowed somewhere and never prints an error, that's why this was so difficult to track down. The error that is thrown is XCB_MATCH (8). So the only reason the tray icon is displayed in the wrong position is because we did not properly catch the exception and thus never removed the tray icon.

I have now read the manpage for xcb_change_window_attributes and there it says:

If XCB_BACK_PIXMAP_PARENT_RELATIVE is specified, the parent's background is used, but the window must have the same depth as the parent (or a Match error results).

So it means that the tray container window has a different depth than the cloud-drive-ui tray icon window.

I really have no idea how to fix this because when we just not configure the background pixmap of the tray icon, we get some weird artifacts for some windows. And just printing an error for this icon doesn't seem like a good idea either.

It's getting late here and I really don't have more time to spend on this, but I'll try to come back at a later point and see what can be done and maybe compare with how stalonetray handles this.

If any of you have any idea how to tackle this, please let us know ;)

---

For reference, here is the patch I am using right now:

diff --git a/src/x11/tray_manager.cpp b/src/x11/tray_manager.cpp
index da2793b4..8b7dc9c8 100644
--- a/src/x11/tray_manager.cpp
+++ b/src/x11/tray_manager.cpp
@@ -769,7 +769,7 @@ void tray_manager::process_docking_request(xcb_window_t win) {
       m_log.trace("tray: Map client");
       m_connection.map_window_checked(client->window());
     }
-  } catch (const xpp::x::error::window& err) {
+  } catch (const exception& err) {
     m_log.err("Failed to setup tray client, removing... (%s)", err.what());
     remove_client(win, false);
   }

With this the icon is no longer misplaced because it is not displayed because polybar now properly fails to setup the tray icon and removes it again.

[moonwitch]

I am way in over my head for this, but I won't give up.

I feel the issue is the XCB implementation of cloud-drive-ui, however I am not finding the source for it. Going to look at that too, but this is 100% new for me.

[rjhilgefort]

I know it's been quite a while on this but I'm having this same issue. Anyone have any leads on how to fix this or a workaround for it?

[mwip]

In the meantime I switched to Xmonad and use stalonetray as a systemtray. It happens to work just fine with the synology icon.

[mbugert]

Synology seem to have fixed the issue in version 2.0.3-11102 of the Drive client. On my end (i3 version 4.17.1 and polybar 3.4.2) the icon now appears in the tray as expected. 🎉

[rjhilgefort]

Same for me!

[moonwitch]

Same for me as well!

[nicolas-rdgs]

Same here!

[kronn]

The AUR-Page https://aur.archlinux.org/packages/synology-drive/ links to .deb-Files, so I can say: works on Ubuntu 18.04 LTS as well.