Open Bug 315947 Opened 15 years ago Updated 6 years ago
Window title not updated when a character of the title is outside the WM charset
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051025 Firefox/1.5 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051025 Firefox/1.5 When the title of a web page contains a character that is not in the charset of the window manager, the window title is not changed. This bug is similar to bug 150131. Here the window title is not updated at all, making things confusing. This is much more serious as in a tabbed browser, one may think to be on another web site: one still gets the title of the previously selected tab, a bit like in bug 250423. Reproducible: Always Steps to Reproduce: 1. Use ISO-8859-1 locales. 2. Start Firefox. 3. Open a webpage with a Euro symbol (I'll provide a testcase) in a new tab. Actual Results: The page is displayed, but the window title is still the one of the home page (the page displayed after starting firefox). Expected Results: The window title should be changed. If for some reason the characters can't be displayed, some default could be displayed, but in any case, the old title MUST NOT be kept.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051025 Firefox/1.5 This WFM here on Linux. When opening the testcase in a new tab and switching to that tab, the window title changes to "? - Mozilla Firefox", i.e. the Euro symbol is replaced with a question mark. Window decoration font on my desktop is Helvetica, which does not contain the Euro symbol. Switching back and forth between tabs also changes the title correctly.
I forgot to recall what I said in bug 250423: I'm using the window manager FVWM2 under ISO-8859-1 locales. _NET_WM_NAME-aware window managers would not be affected by this bug.
Ok, it seems that Firefox doesn't update WM_NAME and WM_ICON_NAME at all when its contents cannot be represented as STRING (or COMPOUND_TEXT as mentioned in bug 118700). Confirming, I see this with fvwm2 here, too.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Depending on the viewpoint, it's not our bug. At http://lxr.mozilla.org/seamonkey/source/widget/src/gtk2/nsWindow.cpp#1099, we just call gtk_set_window_title() delegating the responsibility to gtk2. We can add a fallback/workaround, but I guess it's better to file a 'bug' in the upstream. (http://bugzilla.gnome.org ) gtk1 has a little different story.
(In reply to comment #5) > we just call gtk_set_window_title() delegating the responsibility to gtk2. > > We can add a fallback/workaround, but I guess it's better to file a 'bug' in > the upstream. (http://bugzilla.gnome.org ) Or even better would be to ask fvwm* folks to add support for _NET_WM*.
(In reply to comment #6) > (In reply to comment #5) > > we just call gtk_set_window_title() delegating the responsibility to gtk2. > > > > We can add a fallback/workaround, but I guess it's better to file a 'bug' in > > the upstream. (http://bugzilla.gnome.org ) http://bugzilla.gnome.org/show_bug.cgi?id=321707 > Or even better would be to ask fvwm* folks to add support for _NET_WM*. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339586
I see this bug with Sawfish WM under debian-amd64/unstable. See also bug 320784.
*** Bug 320784 has been marked as a duplicate of this bug. ***
Seen with Mozilla/5.0 (X11; Linux i686; rv:32.0) Gecko/20100101 Firefox/32.0 Iceweasel/32.0a2 and icewm. But wait, with chromium we see https://code.google.com/p/chromium/issues/detail?id=378096
You need to log in before you can comment on or make changes to this bug.