88384 - Window titles longer than 30 chars are being corrupted

Status: RESOLVED FIXED

(Core :: XUL, defect, P3)

Description

[Chris Abbey]

For some reason many of the window titles for various pages are being corrupted.
Title lenght may have something to do with it, but it doesn't seem to be a
certain point where it breaks, for example adding a couple characters to it will
sometimes fix it.

This is happening all over the net... b.m.o for example comes up as "?C" instead
of "mozilla.org Bugzilla -- the Mozilla bug database" but one of the pages I'm
hacking on comes up as "al@rWorks : Open source : Jikes : Summary" instead of
"developerWorks : Open source : Jikes : Summary". The corruption always seems to
be at the begining, and regularly cuts the title short... I suspect someone is
walking off the end of whatever is allocated in memory just before the title
string and trounces the begining of it. Perhaps the addition of a few characters
makes the resulting object too big for that space in memory?

Can someone with a purify or electric fence build maybe try this? I'm able to
repro it with a clobber build that completed pull on Thu Jun 28 21:08:39 CDT
2001. (I'll wait for the tree to be extinguished before pulling today thanks ;)
Running on RH 7.1 on SMP x86 with KDE for a desktop, but I don't believe it's
specific to any of that.

Comment 1

[Chris Abbey]

fwiw, I see that they're ok in the history list and task menu... and they do
seem to sometimes change how they're rendered... this page is claiming to be
"PB" this time, whereas a second ago it was "x[Q??~".

/me hates heap corruption. :(

Comment 2

[Asa Dotzler [:asa]]

->XPApps.  The Browser-General Component is for bugs which don't fit into any
other component. http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Comment 3

[Kelson]

I see this too... build 2001063021, RedHat 6.2 on x86 (single-processor kernel)
w/ KDE 1.2.  "View->Page Info" shows correct title.  Some pages seem okay,
others don't.  I agree that it seems to be leght related but without a specific
cutoff point.  Also, reloading the page changes the garbage characters.

Comment 4

[sairuh (rarely reading bugmail)]

->claudius, for window stuff.

fwiw, i cannot repro this using a 18:30 [y'day, 7/2] mozilla debug on linux [RH
6.2, gnome desktop using sawmill], at least checking the browser window, source
window and page info window while viewing http://bugzilla.mozilla.org...

is there another page, or an additional series of steps i need to follow to see
this?

Comment 5

[Matthew Cline]

With build 2001070318 on Linux 2.4.5-ac17, RedHat 6.1, XFree86 4.1.0,
KDE 2.1, I get the same thing.  As far as I can tell, any title that's longer
than 30 characters is corrupted.

Marking bug as NEW.

Comment 6

[sairuh (rarely reading bugmail)]

hm, odd. i just created a file with a very long <title>...and i cannot repro
this [using a 21:23 debug mozilla build on linux]. am i still missing something?

Comment 7

[sairuh (rarely reading bugmail)]

Attachment: open this page w/a super-long <title>

Comment 8

[Matthew Cline]

Loading the attachment gets the bug for me; maybe reproducing it has
to do with the window manager.  (I'm using KDE 2.1, with the KDE window
manager, and XFree86 4.1.0)

Anyways, reloading the attachment gives a different set of garbage characters
every time; usually 3 garbage characters, but sometimes 2 or 4.  The
part of the title that's chopped off is always "This is "; after the
garbarge characters is always "a super duper...".  Also, sometimes there
isn't any title at all.

Comment 9

[Kelson]

I'm going with WM-related.  Tonight's build shows the title corruption under KDE
2.1 (I mistyped the version number yesterday), but not under Gnome 1.4 w/
Sawfish or under a plain X session w/ WindowMaker.

The thing is, earlier builds of Mozilla don't have this problem even under KDE.
 This just started in the last few days.

Comment 10

[Chris Abbey]

agreed, I don't see a failure on my old gnome system.

Comment 11

[Chris Abbey]

ok, more screwball data points... I added a diagnostic println to
nsXULWindow::SetTitle() as follows:

printf("\nnsXULWindow::SetTitle(%p = %s)\n", aTitle,
       NS_ConvertUCS2toUTF8(aTitle).get()); //cabbey
what I'm seeing is that titles with addresses in the 0xbfff0000 range are NOT
corrupted, no matter the length (but they all tend to be <= 32 bytes) but any
titles allocated in the range 0x40000000 that are lengthy get corrupted.

Comment 12

[sairuh (rarely reading bugmail)]

akkana, jag, are you able to repro this [since you both use diff wm's]? thx!

Comment 13

[jag (Peter Annema)]

WFM with WindowMaker (2001070508).

Comment 14

[Matthew Cline]

I'm using KDE 2.2beta1, and the problem is still there.

Comment 15

[Matthew Cline]

I've chased the problem further along.  Seems the problem happens when
nsWindow::SetTitle() in widget/src/gtk/nsWindow.cpp attempts to set the
UTF8 title for the window.  What's causing the ruckus are these lines:

      const char * utf8_title = NS_ConvertUCS2toUTF8(aTitle).get();

      XChangeProperty(GDK_DISPLAY(), GDK_WINDOW_XWINDOW(mShell->window),
                    XInternAtom(GDK_DISPLAY(), "_NET_WM_NAME", False),
                    XInternAtom(GDK_DISPLAY(), "UTF8_STRING", False),
                    8, PropModeReplace, (const unsigned char *)utf8_title,
                    strlen(utf8_title)+1);

I don't really know what's causing the problem.  The file in question was last 
modified 2001/06/18, about 11 days before the bug was reported.  Using
strlen() on a utf8 string seems pretty suspicious to me.

Comment 16

[Matthew Cline]

Alright, I think that NS_ConvertUCS2toUTF8() is returning bad strings.
Every time it's called on the same page (via reloading) the first few
characters in the string are different (for the instances when the title
is corrupted), and they match the first few characters in the corrupted title.
Also, UTF8 strings for titles of sites like Bugzilla and Slashdot should
be identical to the plain C ascii string, but they aren't.

I'm guessing that window managers that don't show any bad behavior don't
support NET_WM (whatever that is) or don't support UTF8 encoding for the
_NET_WM_NAME property.

Comment 17

[Chris Abbey]

actually I think strlen on a utf8 string is legit. Just it will return the
number of bytes in the string, not the number of chars, which if the interface
expects utf8 it probably also expects length in bytes not chars.

You're right that this code is the problem, but for a slightly different reason,
have a look at the docs in mozilla/string/doc/string-doc.html which says in one
example:

    // But don't hold onto the pointer longer than the lifetime of the temporary!
    const char* cstring = NS_ConvertUCS2toUTF8(aKey).get(); // BAD! |cstring| is
dangling
    printf("%s\n", cstring);
given a dangling pointer I'd not be surprised that we're getting **** output.
I'll bet the solution to this problem is also in that doc, I need to read more
of it though.

Comment 18

[Chris Abbey]

this was broken by bug 9449's checkin of faulty code... they're working on it.

Comment 19

[Francisco León]

*** Bug 89651 has been marked as a duplicate of this bug. ***

Comment 20

[Francisco León]

Keywords->nsCatFood: this is really ugly for the users to see, and it will get
them chased away
I am also using kde 2.1.1 and xfree 4.1.0

Comment 21

[Chris Abbey]

Ilya's latest patch under 9449 is an improvement, but not 100%... I agree that
the remaining bug appears to be in KDE, as the garbage that's now showing up on
the end of _NET_WM_VISIBLE_NAME as it differs from _NET_WM_NAME appears to be
paritally left overs from previous titles.

Comment 22

[Francisco León]

I just submitted to KDE this problem 
Please wait until i get a response for them (i invited them in here too)

Comment 23

[Ilya Konstantinov]

Mozilla behaves correctly (UTF8_STRINGs are not to be null-terminated 
according to standard). I've patched kdelibs/kdecore/netwm.cpp and the fixed 
version should be available in final KDE 2.2 (or the next KDE 2.2 beta 
release, if there's to be one before the final). If you have opened a KDE bug, 
feel free to close it :)

The corruption of the FIRST characters is indeed a bug, which is remedied by 
my second patch attached to bug 9449. The addition of one last garbage 
character is a KDE bug.

If you want a temporary fix, get kdelibs/kdecore/netwm* from CVS, compile with 
gcc -L/usr/X11R6/lib -lX11 netwm.cpp -shared -o netwm.so
and set LD_PRELOAD=/path/to/netwm.so before running KWin.

Comment 24

[Paul Chen]

nav triage team:

Marking nsbeta1+, p3, and mozilla1.2. Note, 9449 has been marked future.

Comment 25

[James Lariviere]

*** Bug 89987 has been marked as a duplicate of this bug. ***

Comment 26

[Francisco León]

mozilla 1.2? If you are going to put a bug to fix in about 10 months, then put
it as future
What about Ilya's patch? Isn't that one supposed to fix mozilla's problem? If
kde has the problem then this bug can be set as fixed after the patch  goes into
nightlies

Comment 27

[Chris Abbey]

I suspect the "future" state of 9449 is because it is a tracking bug that
orriginated in July of 1999 for getting handling of non-ascii titles into all
platforms....  Ilya's latest patch in there, PLUS a fix to KDE (which seems to
be dependent on 2.2, I can't make it work with 2.1, it kills startkde totally)
is the magic bullet that will kill this latest bug in that implemementation.
(this is why I didn't dup this bug onto 9449)

Ilya wrote: "The addition of one last garbage character is a KDE bug."

For the record I've seen it with more than one trailing character, infact the
other night I had soemthing like "0000}00000}00}0000}0}" trailing off the end.
I've also learned that multiline titles aren't handled very well. ;)   (about
three or four times there's been a newline in the garbage, looks real wierd.)

Comment 28

[Aleksey Nogin]

Mozilla1.2 is totally wrong here, bug 9449 has a simple patch (attachment 41121 [details] [diff] [review])
that is believed to fix this problem. 

If not, I would advocate rolling back the original bug 9449 patch (attachment
36404 [review]) that caused this problem since that attachment causes more problems that
it solves, especially for people who do not care as much about non-ASCII titles.

In any case, I believe this should be solved for 0.9.3; waiting for 1.2 with
such an annoying problem when a simple fix exists is unreasonable.

Comment 29

[Boris Zbarsky [:bzbarsky]]

*** Bug 90292 has been marked as a duplicate of this bug. ***

Comment 30

[sairuh (rarely reading bugmail)]

*** Bug 90358 has been marked as a duplicate of this bug. ***

Comment 31

[James Lariviere]

Jag's checkin for bug 9449 seems to have fixed the title corruption for me.

THis now is WFM with linux build 7-14-06 on mandrake8 distro.

Comment 32

[Matthew Cline]

Begining of title corruption fixed (but not end of title) on Linux build
2001071406, Linux 2.4.6-ac2 i686, RedHat 6.1, XFree 4.1.0, KDE 2.2beta1

Comment 33

[Robert Kaiser]

If attachment 41121 [details] [diff] [review] get r=/sr=/whatever it needs, and gets checked in, this bug
should be considered fixed, as the remaining bug (end of title) is the KDE bug
(and resolved in future KDE versions).

So who would be needed for/give us the reviews and checkin we need?

Comment 34

[jag (Peter Annema)]

That has r=/sr= and was checked in. If that means this bug is fixed, someone
please mark it so.

Comment 35

[Mark Schonbach]

WFM under 2001071506.  KDE 2.2beta1

Comment 36

[Francisco León]

*** Bug 91119 has been marked as a duplicate of this bug. ***

Comment 37

[Aleksey Nogin]

Yes, this bug was fixed by a checkin for bug 9449.
P.S. I am testing it using build id 2001072012 under KDE on RH Linux 7.1 

Comment 38

[sairuh (rarely reading bugmail)]

*** Bug 92150 has been marked as a duplicate of this bug. ***