WM_TAKE_FOCUS messages can have wrong timestamp

[luke-jr]

Describe the bug
Somehow xpra is sending applications WM_TAKE_FOCUS with the wrong timestamp. This confuses Qt and causes copy-to-clipboard to fail with qt.qpa.clipboard: QXcbClipboard::setMimeData: Cannot set X11 selection owner

It usually only happens after several weeks of uptime. Restarting xpra doesn't seem to help.

To Reproduce
Steps to reproduce the behavior:

1. Wait several weeks. In my most recent occurrence, it began causing issues after 37 days.
2. Open kwrite or some other Qt application with copy-to-clipboard functionality
3. Attempt to copy to clipboard.

System Information (please complete the following information):

• Server OS: Linux
• Client OS: Linux
• Xpra Server Version: 5.0.10
• Xpra Client Version: 6.0.1

Additional context
Add any other context about the problem here.
Please see "reporting bugs" in the wiki section.

[totaam]

Looks like the same issue as #4439

The helpful hint was the 37 days:

round(2**32/1000/60/60/24)
50

I think that this is a regression caused by fef8b55 in v5.

The actual code setting the focus is here:

xpra/xpra/x11/models/window.py

Lines 926 to 955 in d43630d

	def do_give_client_focus(self) -> None:
	protocols = self.get_property("protocols")
	focuslog("Giving focus to %#x, input_field=%s, FORCE_XSETINPUTFOCUS=%s, protocols=%s",
	self.xid, self._input_field, FORCE_XSETINPUTFOCUS, protocols)
	# Have to fetch the time, not just use CurrentTime, both because ICCCM
	# says that WM_TAKE_FOCUS must use a real time and because there are
	# genuine race conditions here (e.g. suppose the client does not
	# actually get around to requesting the focus until after we have
	# already changed our mind and decided to give it to someone else).
	now = X11Window.get_server_time(self.corral_xid)
	# ICCCM 4.1.7 *claims* to describe how we are supposed to give focus
	# to a window, but it is completely opaque. From reading the
	# metacity, kwin, gtk+, and qt code, it appears that the actual rules
	# for giving focus are:
	# -- the WM_HINTS input field determines whether the WM should call
	# XSetInputFocus
	# -- independently, the WM_TAKE_FOCUS protocol determines whether
	# the WM should send a WM_TAKE_FOCUS ClientMessage.
	# If both are set, both methods MUST be used together. For example,
	# GTK+ apps respect WM_TAKE_FOCUS alone, but I'm not sure they handle
	# XSetInputFocus well, while Qt apps ignore (!!!) WM_TAKE_FOCUS
	# (unless they have a modal window), and just expect to get focus from
	# the WM's XSetInputFocus.
	if bool(self._input_field) or FORCE_XSETINPUTFOCUS:
	focuslog("... using XSetInputFocus")
	X11Window.XSetInputFocus(self.xid, now)
	if "WM_TAKE_FOCUS" in protocols:
	focuslog("... using WM_TAKE_FOCUS")
	send_wm_take_focus(self.xid, now)
	self.set_active()

And the server time is obtained from here:

xpra/xpra/x11/bindings/window.pyx

Lines 1434 to 1445 in 3e25ef4

	def get_server_time(self, Window xwindow) -> long:
	cdef unsigned char c = b"a"
	cdef Atom timestamp_prop = self.str_to_atom("XPRA_TIMESTAMP_PROP")
	XChangeProperty(self.display, xwindow, timestamp_prop,
	timestamp_prop,
	8, PropModeReplace, &c, 1)
	cdef XEvent xevent
	cdef xifevent_timestamp et
	et.window = xwindow
	et.atom = timestamp_prop
	XIfEvent(self.display, &xevent, <void*> &timestamp_predicate, <XPointer> &et)
	return xevent.xproperty.time

By inspecting the generated C code, I believe that 3e25ef4 should fix this.
Though it may take up to ~50 days to confirm!