Xpra: Ticket #826: Title bar don't support Unicode

Server: Trusty with xpra 0.15 r8802 Client: MS Windows 7 with xpra 0.15 r8826

Title bar don't support Unicode. Unicode chars become '?' char. Previous version as 0.14.x support Unicode very well.



Tue, 24 Mar 2015 04:49:53 GMT - Antoine Martin: status changed; milestone set

Thanks for the bug report. Python3 support (#90 / #640) makes this such a pain.


Wed, 15 Apr 2015 04:20:37 GMT - Antoine Martin: owner, status changed

I'm not seeing any problems with 0.14 or 0.15 on Linux. It doesn't work on MS Windows, but it never has - see #526.

@John1221: what do you mean by "previous as 0.14.x support Unicode very well".


Thu, 16 Apr 2015 02:16:40 GMT - John1221: owner changed

Replying to antoine:

I'm not seeing any problems with 0.14 or 0.15 on Linux. It doesn't work on MS Windows, but it never has - see #526.

But I saw it works. My server is trusty and my client is MS Windows 7. And It will work if I use xpra 0.14.x at both server and client or server(0.15), client(0.14.x). (Server 0.15, client 0.15) or (server 0.14.x, client 0.15) don't work. Do you have already tested with these cases ?

@John1221: what do you mean by "previous as 0.14.x support Unicode very well".

I mean all of xpra 0.14.x versions. I tested this bug like this:

Hope this helps.


Tue, 21 Apr 2015 16:28:56 GMT - Antoine Martin: attachment set

patch useful for debugging


Tue, 21 Apr 2015 16:56:11 GMT - Antoine Martin: status changed

Applying the patch above to both branches and comparing the output with diff:

 atvar=@title@
 var=title
 default_value=<untitled window>
-type(Find with keyword "â ? ? ? ? ? á à ? ã ? ê ? )=<type 'str'>
-value=Find with keyword "â ? ? ? ?? á à ? ã ? ê ?
-=Find with keyword "â ? ? ? ? ? á à ? ã ? ê ?
+type(Find with keyword "â ? ? ? ? ? á à ? ã ? ê ? ? ? ?)=<type 'str'>
+value=Find with keyword "â ? ? ? ? ? á à ? ã ? ê ? ? ? ?
+=Find with keyword "â ? ? ? ? ? á à ? ã ? ê ? ? ? ?
 atvar=@client-machine@
 var=client-machine
 default_value=<unknown machine>
 type(desktop)=<type 'str'>
 value=desktop
 =desktop
-title after substitution=Find with keyword "â ? ? ? ? ? á à ? ã ? ê ?  on desktop
+title after substitution=Find with keyword "â ? ? ? ? ? á à ? ã ? ê ? ? ? ? on desktop

Is useless, because windows is being rubbish at handling those strings - what a surprise, not.


Wed, 22 Apr 2015 04:00:20 GMT - Antoine Martin: milestone changed

(this affects 0.15 not 0.14 - updating milestone)


Wed, 22 Apr 2015 09:22:45 GMT - Antoine Martin:

Testing with a 0.14 server and a patch which I will attach:


Wed, 22 Apr 2015 09:23:19 GMT - Antoine Martin: attachment set

patch for both branches


Thu, 23 Apr 2015 06:31:26 GMT - Antoine Martin:

So the "good" news is that XP does the same thing as win7, which makes it easier for me to test. And 0.15 does the same thing as 0.14, the "title after substitution" is the same... And that's bad because it means that something else in the environment is affecting the set_title call.

And then the plot thickens some more: if I connect to an existing session, the utf string is the same and the title is displayed properly initially (at least on win7), but if I change a single character, the update makes it garbled - even if I change it back!? (that's probably why I had created #526)

And finally, on a hunch I tried starting the client with:

XPRA_WIN32_WINDOW_HOOKS=0

And the title displayed properly every time. So something in those hooks is making GTK unhappy.. and making me unhappy about GTK even more.

r9126 makes it easier to test with the same string everytime (no need for a browser by the way):

./tests/xpra/test_apps/test_window_title.py  "â ậ ấ ầ ẩ ẫ á à ạ ã ả ê ệ ế ề ể ễ ẹ é è ẻ ẽ ô ộ ố ồ ổ ỗ ọ ó ò ỏ õ"

And r9127 allows us to turn off win32 window overrides individually (worth having for the future too). With this change I found that the override that causes the title to get garbled is the MAX_SIZE_HINT one!???? Probably something in the Win32Hooks class, though it looks just fine.


Thu, 23 Apr 2015 13:14:57 GMT - Antoine Martin: attachment set

allows us to try many different ways of setting the title


Thu, 23 Apr 2015 13:24:27 GMT - Antoine Martin:

The patch above allows us to try 4 different ways of setting the window title, apart from GTK's default implementation which does this:

wtitle = g_utf8_to_utf16 (title, -1, NULL, NULL, NULL);
API_CALL (SetWindowTextW, (GDK_WINDOW_HWND (window), wtitle));

Coupled with the ability to change the character encoding using the env var WM_TEXT_ENCODING and with the ability to choose which hooks we enable (see comment:7). We end up with dozens of combinations... and none of them work. But I eventually found something interesting: when we enable MAX_SIZE_HINT, the debug output always shows:

user32.IsWindowUnicode=False

Whereas it is True when this is disabled!? So somehow, we end up disabling unicode support by registering our window handler?!?

Some relevant links:

Weird and frustrating.


Thu, 23 Apr 2015 15:10:06 GMT - Antoine Martin: owner, status changed

With r9136, we can disable everything else (the message map is empty, we don't hook the methods on the window class), which confirms that just hooking up the window proc is enough to make it misbehave.

Sounded similar to: Why would Unicode Windows title-bars (only) be question mark (?) code points?.

The strange thing was that we were using the totally standard way of Hooking The Wnd Proc via pywin32's win32gui (examples abound online), and there are no pywin32 wrappers for SetWindowLongW...

But using the ctypes version in r9137 fixes things at last!

@John1221: can you please confirm that the latest beta 0.15 builds for Windows fix the issue for you? (I will take a look tomorrow at 0.15 servers, since from what you reported there may also be a problem at that end - seems to work for me, but I am on a newer revision than you were, maybe that's the problem - building new rpm and deb packages now)


Fri, 24 Apr 2015 02:27:39 GMT - John1221: owner changed

@antoine: So good!! I tested with r9137 for Windows client, and the issue is fixed. PS: server-side: Trusty 0.14.22 and 0.15 r9137


Fri, 24 Apr 2015 02:31:52 GMT - Antoine Martin: status changed; resolution set

@John1221: I can't see any problems with 0.15 servers either. So I am closing this ticket. Feel free to re-open if you have problems with the latest 0.15 beta servers (just posted a new build).


Fri, 24 Apr 2015 02:45:04 GMT - John1221:

I've just tested the latest 0.15 beta servers ( trusty) and don't see any problems, too. Thank you for your support. :)


Fri, 24 Apr 2015 06:06:33 GMT - Antoine Martin:

Well, obviously it was not the end: r9143 was needed to fix the py3k builds which broke as a result of r9137.


Sat, 23 Jan 2021 05:07:11 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/826