Open Bug 1679182 Opened 4 years ago Updated 11 months ago

WM_NAME stopped getting set from document.title (new problem in Firefox 83.0)

Categories

(Core :: Widget: Gtk, defect, P5)

Product:
Core
Component:
Widget: Gtk
Version:
Firefox 83
Type:
defect

Tracking

()

People

(Reporter: reikred, Unassigned)

References

(Regression)

Details

(Keywords: regression)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:82.0) Gecko/20100101 Firefox/82.0

Steps to reproduce:

Update firefox 82.0.3 to 83.0, restart firefox. As an example, visit the URL https://www.yahoo.com/news

Actual results:

The X11 property WM_NAME is not properly set in each tab anymore. It looks like someone has been hacking on the code and created a bug. This is a NEW bug in firefox 83.0, so it should be reasonably easy for an expert to locate the code that changed.

% xprop | grep WM_NAME
WM_NAME(STRING) = "Mozilla Firefox" <------THIS IS WRONG
_NET_WM_NAME(UTF8_STRING) = "Yahoo News - Latest News & Headlines - Mozilla Firefox"

Window managers use WM_NAME to, among other things, sort and display the names of windows so that it easier to find the desired window among a set of windows. If it is not set correctly, different windows will get the same name
"Mozilla Firefox", which is very unhelpful.

You may notice that the possibly related _NET_WM_NAME property does contain the correct value.

Expected results:

In firefox-82.0.3 everything is okay, as it has been for many years, and WM_NAME gets set properly (from the html document.title, I think).

% xprop | grep "WM_NAME"
WM_NAME(STRING) = "Yahoo News - Latest News & Headlines - Mozilla Firefox"
_NET_WM_NAME(UTF8_STRING) = "Yahoo News - Latest News & Headlines - Mozilla Firefox"

Probably related to the change in bug 1279647.

Still, not exactly sure if the string is generated by Firefox, or that's something else making assumptions while parsing the window's title? I can only find references to _NET_WM_NAME in the code.

See Also: → 1279647

(In reply to Francesco Lodolo [:flod] from comment #1)

Probably related to the change in bug 1279647.

Still, not exactly sure if the string is generated by Firefox, or that's something else making assumptions while parsing the window's title? I can only find references to _NET_WM_NAME in the code.

Did you look in the source of 82.0.3 (not just 83.0) for WM_NAME? Some code in firefox as recently as 82.0.3 must has been (correctly) setting WM_NAME in real time after each loading a webpage, I can see no other explanation.

I should note that I changed nothing apart from installing 83.0. I also still have 82.0.3, so I ran the tests side by side and saw the different behavior. So it must be firefox that changed, I am fairly certain.

I wonder if WM_NAME doesn't support UTF8?

I don't understand wy it's getting the text after the emdash though. I would think it would be before.

Only WM_NAME code is here

https://searchfox.org/mozilla-central/source/widget/gtk/nsWindow.cpp#1901

:mkaply I think it is a good bet that WM_NAME is supposed to be plain ascii. So the right thing to do is if _NET_WM_NAME has been changed from ascii to utf-8, the right thing to do is to populate WM_NAME with a best-effort ascii-fication of _NET_WM_NAME.

I'm not enough of a firefox hacker (or any kind of hacker) to understand what you changed, but to me it looks like the aforementioned is what is going on.

Reference/note to self: This appears to be the changes made
https://hg.mozilla.org/mozilla-central/rev/7dbc11b10cb06d65133570a6d14e64e110756f4b

What GTK version and distribution are you using?
For me everything looks okay:

> xprop | grep WM_NAME
WM_NAME(COMPOUND_TEXT) = "1679182 - WM_NAME stopped getting set from document.title (new problem in Firefox 83.0) — Firefox Nightly"
_NET_WM_NAME(UTF8_STRING) = "1679182 - WM_NAME stopped getting set from document.title (new problem in Firefox 83.0) — Firefox Nightly"
Component: Untriaged → Widget: Gtk
Product: Firefox → Core

https://searchfox.org/mozilla-central/rev/85b84f82489451362a351b144fe5232a8e46c61c/widget/gtk/nsWindow.cpp#2471 is the code that should run when we set the title, so probably this is a GTK issue (if this is not expected due to stuff not being valid ascii).

(In reply to Tom Schuster [:evilpie] from comment #5)

% m /proc/2378737/cmdline
/usr/local/firefox-83.0/firefox

% grep gtk /proc/2378737/maps
7f4474876000-7f4474879000 r--p 00000000 08:02 526292 /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-ibus.so
7f4474879000-7f447487d000 r-xp 00003000 08:02 526292 /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-ibus.so
7f447487d000-7f447487f000 r--p 00007000 08:02 526292 /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-ibus.so
7f447487f000-7f4474880000 r--p 00008000 08:02 526292 /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-ibus.so
7f4474880000-7f4474881000 rw-p 00009000 08:02 526292 /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-ibus.so
7f44791ca000-7f4479300000 r--p 00000000 08:02 3678364 /usr/share/themes/Yaru/gtk-3.20/gtk.gresource
7f4487875000-7f44878fa000 r--p 00000000 08:02 402253 /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2404.16
7f44878fa000-7f4487c69000 r-xp 00085000 08:02 402253 /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2404.16
7f4487c69000-7f448800d000 r--p 003f4000 08:02 402253 /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2404.16
7f448800d000-7f448801e000 r--p 00797000 08:02 402253 /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2404.16
7f448801e000-7f4488020000 rw-p 007a8000 08:02 402253 /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2404.16
7f4488d10000-7f4488d11000 r--p 00000000 08:02 404911 /usr/local/firefox-83.0/libmozgtk.so
7f4488d11000-7f4488d12000 r-xp 00001000 08:02 404911 /usr/local/firefox-83.0/libmozgtk.so
7f4488d12000-7f4488d13000 r--p 00002000 08:02 404911 /usr/local/firefox-83.0/libmozgtk.so
7f4488d13000-7f4488d14000 r--p 00002000 08:02 404911 /usr/local/firefox-83.0/libmozgtk.so
7f4488d14000-7f4488d15000 rw-p 00003000 08:02 404911 /usr/local/firefox-83.0/libmozgtk.so
%

Does the above tell you what you need to know about which gtk I am running? I am on ubuntu 20.04
Here are some more details:

% dpkg -l 'libgtk*' | grep -e '^i' | grep -e 'libgtk-*[0-9]'
ii libgtk-3-0:amd64 3.24.20-0ubuntu1 amd64 GTK graphical user interface library
ii libgtk-3-bin 3.24.20-0ubuntu1 amd64 programs for the GTK graphical user interface library
ii libgtk-3-common 3.24.20-0ubuntu1 all common files for the GTK graphical user interface library
ii libgtk2-perl 2:1.24993-1ubuntu2 amd64 Perl interface to the 2.x series of the Gimp Toolkit library
ii libgtk2.0-0:amd64 2.24.32-4ubuntu4 amd64 GTK graphical user interface library - old version
ii libgtk2.0-0:i386 2.24.32-4ubuntu4 i386 GTK graphical user interface library - old version
ii libgtk2.0-bin 2.24.32-4ubuntu4 amd64 programs for the GTK graphical user interface library
ii libgtk2.0-common 2.24.32-4ubuntu4 all common files for the GTK graphical user interface library
ii libgtk3-perl 0.037-1 all Perl bindings for the GTK+ graphical user interface library
%
How does that match up with the version you are running? I do not see any available libgtk updates in my ubuntu.

That looks similar to my installation. Are you maybe using a non-UTF8 locale?

(In reply to Tom Schuster [:evilpie] from comment #8)

That looks similar to my installation. Are you maybe using a non-UTF8 locale?

That was a good question, Tom. I was running with the C/POSIX locale values and LANG=en_US not en_US.utf8 (which I have never used before, and did not know the significance of).

% locale
LANG=en_US
LANGUAGE=
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=C

The fix is setting LC_ALL=en_US.UTF-8, that is, invoking firefox-83.0 with

env LC_ALL=en_US.UTF-8 /usr/local/firefox-83.0/firefox,

The original problem then goes away. WM_NAME now gets the datatype COMPOUND_TEXT also in my case, rather than STRING. Tthat is, same datatype as seen in your xprop output, and that works also for me.

I guess that one "emdash" UTF-8 cosmetic change made in https://hg.mozilla.org/mozilla-central/rev/7dbc11b10cb06d65133570a6d14e64e110756f4b changed how everything behaves. Is there any other lesson to be learned here? I'm not sure, maybe the experts have an opinion.

Martin,

Would you know anything about this or who could help?

This seems like this would be a fragile system with any Window title that uses UTF8 though.

Flags: needinfo?(stransky)

reikred,
I'd like to reproduce it before I do any conclusion but it works for me and I tested various locales, LC_ALL=C included.
Which Firefox version do you run, is that a snap from Ubuntu or some binary? Can you test that with binaries downloaded directly from mozilla?
How-to is here:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Testing_Mozilla_binaries
Thanks.

Flags: needinfo?(stransky) → needinfo?(reikred)
Priority: -- → P3

Martin, I always get firefox straight from mozilla, in this case https://ftp.mozilla.org/pub/firefox/releases/83.0/linux-x86_64/en-US/.

Are you saying that for youm WM_NAME does get set to something else than "Mozilla Firefox"?

% xprop | grep WM_NAME
WM_NAME(STRING) = "Mozilla Firefox" <------THIS IS WRONG, SHOULD HAVE VALUE FROM WEBSITE, SEE NEXT LINE.
_NET_WM_NAME(UTF8_STRING) = "Yahoo News - Latest News & Headlines - Mozilla Firefox"

when you run a test with linux and X11?

Flags: needinfo?(reikred)

You're right, I get:

WM_NAME(STRING) = "Mozilla Firefox"
_NET_WM_NAME(UTF8_STRING) = "Tokyo prosecutors consider summary indictment of ex-PM Abe officials: Asahi — Mozilla Firefox"

but what's exactly wrong? Do you think _NET_WM_NAME should be the same as WM_NAME or do you think WM_NAME has a string type?

Okay, so Martin is getting the same behavior as I do.

Now, what is wrong is that WM_NAME is not getting the correct document title as exhibited in _NET_WM_NAME, because some code punts on the conversion, that is, will not make WM_NAME into datatype COMPOUND_TEXT unless LC_ALL=en_US.UTF-8 is set. That's what Tom Schuster [:evilpie] guessed, and he was right.

It appears that smarter people than I think that Firefox ought to set proper WM_NAME value even when the document title contains utf-8 characters. ALSO when LC_ALL=C. The question appears to be, how to achieve that.

We use only gtk_window_set_title() Gtk function to set the window title. If the function behaves wrongly it should be reported/escalated at https://gitlab.gnome.org/GNOME/gtk

AFAIK There isn't any Firefox hack to set WM_NAME or _NET_WM_NAME or so.

Martin, What behavior would you ask GTK to change? I'll present an argument that it is mozilla that needs to change, and how it should change. Let's have a look. As (:emilio) noted above, the relevant source code in mozilla is found in:

https://searchfox.org/mozilla-central/rev/85b84f82489451362a351b144fe5232a8e46c61c/widget/gtk/nsWindow.cpp#2471

The snippet of code that relates to our topic is:

NS_ConvertUTF16toUTF8 titleUTF8(aTitle);
if (titleUTF8.Length() > NS_WINDOW_TITLE_MAX_LENGTH) {
// Truncate overlong titles (bug 167315). Make sure we chop after a
// complete sequence by making sure the next char isn't a follow-byte.
uint32_t len = NS_WINDOW_TITLE_MAX_LENGTH;
while (UTF8_FOLLOWBYTE(titleUTF8[len])) --len;
titleUTF8.Truncate(len);
}
gtk_window_set_title(GTK_WINDOW(mShell), (const char*)titleUTF8.get());

Mozilla converts the aTitle value from UTF16 to UTF8 and then stuffs the result into a GTK function without checking whether GTK is running in an environment where UTF8 is supported. I think one could argue that mozilla should check LC_LANG and/or LC_ALL to see if GTK can be expected handle the titleUTF8 value. If not, perhaps the right thing to do is to convert (before calling GTK) the value to plain ASCII and substitute question marks (say) for any character that is not plain ASCII. Maybe there already exists a function that does such conversion.

Is this the right way to look at the issue? If the title from WM_NAME appears with some ??? in it, at least it is partially meaningful. And also there is an indication that something may be up with character encoding and locale settings. If WM_NAME just silently falls back to the value "Mozilla Firefox", the user has no idea what happened and there is zero usable information in the string.

(In reply to reikred from comment #16)

Martin, What behavior would you ask GTK to change? I'll present an argument that it is mozilla that needs to change, and how it should change. Let's have a look. As (:emilio) noted above, the relevant source code in mozilla is found in:

https://searchfox.org/mozilla-central/rev/85b84f82489451362a351b144fe5232a8e46c61c/widget/gtk/nsWindow.cpp#2471

The snippet of code that relates to our topic is:

NS_ConvertUTF16toUTF8 titleUTF8(aTitle);
if (titleUTF8.Length() > NS_WINDOW_TITLE_MAX_LENGTH) {
// Truncate overlong titles (bug 167315). Make sure we chop after a
// complete sequence by making sure the next char isn't a follow-byte.
uint32_t len = NS_WINDOW_TITLE_MAX_LENGTH;
while (UTF8_FOLLOWBYTE(titleUTF8[len])) --len;
titleUTF8.Truncate(len);
}
gtk_window_set_title(GTK_WINDOW(mShell), (const char*)titleUTF8.get());

Mozilla converts the aTitle value from UTF16 to UTF8 and then stuffs the result into a GTK function without checking whether GTK is running in an environment where UTF8 is supported. I think one could argue that mozilla should check LC_LANG and/or LC_ALL to see if GTK can be expected handle the titleUTF8 value. If not, perhaps the right thing to do is to convert (before calling GTK) the value to plain ASCII and substitute question marks (say) for any character that is not plain ASCII. Maybe there already exists a function that does such conversion.

Is this the right way to look at the issue? If the title from WM_NAME appears with some ??? in it, at least it is partially meaningful. And also there is an indication that something may be up with character encoding and locale settings. If WM_NAME just silently falls back to the value "Mozilla Firefox", the user has no idea what happened and there is zero usable information in the string.

Okay, that makes sense.

After reading the history, it's not clear to me if the problem is understood... If so, then here's a recap :)

As a Window Manager developer, here's my humble assessment:

  1. WM_NAME is using Compound text encoded string, think plain old ASCII with a some extras depending on the locale. But it is not UTF-8
  2. NET_WM_NAME is using UTF-8 encoding
  3. Firefox or GTK is setting the WM_NAME Property with a UTF-8 encoded string.
  4. X11 TextProperty deals with 'string' as char* regardless of the encoding and issue like are more common than you think.. Especially with languages using Latin-1 (English, French, etc).

Link to X11 TextProperty definition : https://tronche.com/gui/x/icccm/sec-2.html#s-2.7.1
Link to NET_WM_NAME spec : https://specifications.freedesktop.org/wm-spec/1.3/ar01s05.html#idm45225103306144

I can confirm that the issue is still present as of v86.01 - Linux x64 (centos 8.3)

Here's my locale setup
LC_ALL=en_US.UTF-8
LANG=en_US.UTF-8
GDM_LANG=en_US.UTF-8
XTERM_LOCALE=en_US.UTF-8

Also, I can confirm that both WM_NAME and NET_WM_NAME PropertyChangeNotifications are sent (for the same tab). Is it a Firefox or GTK issue, dunno.

This is a Gtk issue. Gtk API does not expose the concept of compound text (why? Consider about the Wayland backend). Gtk is responsible to convert between UTF-8 strings and compound text.

(In reply to Masatoshi Kimura [:emk] from comment #22)

This is a Gtk issue. Gtk API does not expose the concept of compound text (why? Consider about the Wayland backend). Gtk is responsible to convert between UTF-8 strings and compound text.

仰るとおりです。 ありがとう!

Guys, do you mind to step in and propose a patch for it? The code may be easy to change, it' s here:

https://searchfox.org/mozilla-central/rev/aa9a7136835deb0eeba00c62bb50a4a0e2cdea2d/widget/gtk/nsWindow.cpp#2560

I wonder if gtk_window_set_wmclass() or gtk_window_set_role() can be used or if we need to set WM_NAME property directly when non UTF-8 locale is selected.

IIUC GTk doc states that gtk_window_set_title() does not do any conversions and result depends on your actual system settings:

gtk_window_set_title (GtkWindow *window, const gchar *title);

Sets the title of the GtkWindow. The title of a window will be displayed in its title bar; on the X Window System, the title bar is rendered by the
window manager, so exactly how the title appears to users may vary according to a user’s exact configuration. The title should help a user
distinguish this window from other windows they may have open. A good title might include the application name and current document
filename, for example.

Based on the GTK doc (not a GTK developer), the fix could be to just use a non UTF-8 string. However, it is unclear how GTK differentiate between a WM_NAME vs. NET_WM_NAME PropertyChangeNotify. The documentation doesn't reflect that. My gut tells me to send directly both Atoms with proper encoding vs. doing backflips with GTK. Would that be acceptable?

Another very temporary solution would be to *not use the double dash chars, but it's more like putting lipstick on a pig...

I wonder if gtk_window_set_wmclass() or gtk_window_set_role() can be used or if we need to set WM_NAME property directly when non UTF-8 locale is selected.

Why do we have to clean up Gtk's mess? Gtk+ should just work when we call gtk_window_set_title(). If not, why do we use an abstraction layer in the first place?

IIUC GTk doc states that gtk_window_set_title() does not do any conversions and result depends on your actual system settings:

It is the generic Glib principle to use UTF-8 strings. Every single function reference does not necessarily explains about that.
https://developer.gnome.org/glib/stable/glib-Character-Set-Conversion.html

Glib uses UTF-8 for its strings, and GUI toolkits like GTK+ that use GLib do the same thing.

Even if the function reference does not explicitly explains about the conversion, Gtk+ with X11 backend will have to make a conversion as a logical consequence.

The Gdk X11 backend actually tries to convert UTF-8 strings to either a string or a compound text (and fails):
https://github.com/GNOME/gtk/blob/a1c1ad317ba428f460563dbcd8d4ba816984a69c/gdk/x11/gdksurface-x11.c#L2592-L2607
https://github.com/GNOME/gtk/blob/a1c1ad317ba428f460563dbcd8d4ba816984a69c/gdk/x11/gdksurface-x11.c#L2542-L2590

Please file a bug against the GNOME project.

(In reply to eric.masson from comment #25)

Based on the GTK doc (not a GTK developer), the fix could be to just use a non UTF-8 string. However, it is unclear how GTK differentiate between a WM_NAME vs. NET_WM_NAME PropertyChangeNotify. The documentation doesn't reflect that. My gut tells me to send directly both Atoms with proper encoding vs. doing backflips with GTK. Would that be acceptable?

Do be careful what you do.
The current GTK code (as at Firefox 86.0) generates the correct title <em>if</em> LANGUAGE is set to a UTF-8 locale.
That is the the value in the environment of the firefox process (I haven't checked what value the X server sees).

#(export LANGUAGE=en_GB.UTF-8 ; firefox &)
#xprop | grep WM_NAME

select window

WM_ICON_NAME(COMPOUND_TEXT) = "1679182 - WM_NAME stopped getting set from document.title (new problem in Firefox 83.0) – Mozilla Firefox"
_NET_WM_ICON_NAME(UTF8_STRING) = "1679182 - WM_NAME stopped getting set from document.title (new problem in Firefox 83.0) – Mozilla Firefox"
WM_NAME(COMPOUND_TEXT) = "1679182 - WM_NAME stopped getting set from document.title (new problem in Firefox 83.0) – Mozilla Firefox"
_NET_WM_NAME(UTF8_STRING) = "1679182 - WM_NAME stopped getting set from document.title (new problem in Firefox 83.0) – Mozilla Firefox"

#(export LANGUAGE=en_GB ; firefox &)
#xprop | grep WM_NAME

select window

_NET_WM_ICON_NAME(UTF8_STRING) = "1679182 - WM_NAME stopped getting set from document.title (new problem in Firefox 83.0) – Mozilla Firefox"
WM_NAME(STRING) = "Mozilla Firefox"
_NET_WM_NAME(UTF8_STRING) = "1679182 - WM_NAME stopped getting set from document.title (new problem in Firefox 83.0) – Mozilla Firefox"

(I see that with the non-UTF-8 LANGUAGE, WM_ICON_NAME is not set.)

Apologies for the shouting in #29 and #30. If anyone can remove the duplicate, please do so.

no worries mate.

Here's my locale setup. No sign of LANGUAGE and LC_ALL set to none. running centos 8.3

$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

(In reply to eric.masson from comment #32)

no worries mate.

Here's my locale setup. No sign of LANGUAGE and LC_ALL set to none. running centos 8.3
Mine was similar (see https://bugzilla.mozilla.org/show_bug.cgi?id=1686074#c3 which is one of the duplicate bugs).

What happens if you set LANGUAGE="en_US.UTF-8" (you might need "export" or "setenv") before starting firefox ?
That was enough to fix it for me on Ubuntu 20.10.

Is the problem that something is using LANGUAGE instead of LANG ?
I note https://searchfox.org/mozilla-central/source/gfx/thebes/gfxFcPlatformFontList.cpp#2439
const char* languages = getenv("LANGUAGE");
Could that be the issue ?

LANGUAGE is used by getext, that I know. I will try something are report back. GN

The problem is still present on 107.0 with fr locale
https://bugzilla.mozilla.org/show_bug.cgi?id=1801503

Duplicate of this bug: 1801503
Regressed by: 1279647

I don't think that 1279647 caused this, just made it visible.

As I already said, bug 1279647 made a Gtk bug visible, not a Firefox one.

It looks like we agree the problem exists, just not where it should be fixed.

Severity: -- → S4
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: P3 → P5
You need to log in before you can comment on or make changes to this bug.