541647 - Missing information in status bar on hover

Status: RESOLVED FIXED

(Other Applications :: ChatZilla, defect)

Description

[neb1236]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2) Gecko/20100115 Firefox/3.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2) Gecko/20100115 Firefox/3.6

Since the update to Firefox 3.6 overing the inside screen of Chatzilla doesn't give anymore information on text only (hovering url does give the url)
Using Firefox 3.5, the status bar work just fine.

Reproducible: Always

Steps to Reproduce:
1. Install firefox 3.6/use clean profile
2. Install chatzilla
3. Go to any IRC channel
4. Hover the line of someone saying something (only text, not url)
5. Look at what the status bar says
Actual Results:  
The status Bar says: "Welcome to Chatzilla!"

Expected Results:  
The status Bar says: [aaaa-mm-jj hh:mm:ss] Nickname![e-mail]

Using latest chatzilla 0.9.86

Comment 1

[James Ross]

This looks like a really crazy Firefox/Core bug, but I can't really make sense of it. The problem is that the HTML:TR node containing the statusText attribute (which has the text for the statusbar in non-link cases) refuses to read the attribute through getAttribute at all.

0001: target.nodeName
$[24] = [string] "HTML:TR"
0001: target.attributes[6].name
$[25] = [string] "statusText"
0001: target.attributes[6].value
$[26] = [string] "[2010-01-23 12:14:08] NickServ![e-mail]"
0001: target.getAttribute("statusText")
$[27] = [null] null

I even tried "statustext" and "STATUSTEXT" in case something was being case-sensitive, but they don't work either. The attributes collection clearly includes it, with the value, but getAttribute() is being... difficult.

I have no idea what's going on.

Comment 2

[neb1236]

Found the build where all started
20090608 build (changeset: 4f11e242a00e) -> good
20090609 build (changeset: 39f1a74e500b) -> bad

official 20090609 tread: http://forums.mozillazine.org/viewtopic.php?f=23&t=1287495

Bug468708 and Bug496532 ? but doesn't seems like

Hope this will help.

Comment 3

[James Ross]

Thanks for finding the build! I'd be highly suspicious of bug 468708, that's the right kind of area to break this stuff; dependent bug 501312 is also pretty suspicious, but more investigation is needed to pin this down.

Comment 4

[James Ross]

It does look like bug 501312 (or something similar) is attacking here. Before we adopt the <tr> into the HTML document:

0001: obj.nodeName
$[0] = [string] "html:tr"
0001: obj.getAttribute("statusText")
$[1] = [string] "[2010-01-23 13:49:07] NickServ![e-mail]"

After adoptNode():

0001: obj.nodeName
$[0] = [string] "HTML:TR"
0001: obj.getAttribute("statusText")
$[1] = [null] null

The change of nodeName's case is another interesting side-effect (which I'd totally call a bug but is probably intentional).

Comment 5

[James Ross]

Attachment: Testcase for adoptNode() corruption

Comment 6

[James Ross]

Attachment: Rename attribute to avoid bug 501312

Comment 7

[neb1236]

I tried the modification and it works just great now, good work.

Comment 8

[:Gijs (he/him)]

Comment on attachment 423188 [details] [diff] [review]
Rename attribute to avoid bug 501312

I'm really confused because bug 501312 has two attributes with conflicting case. We only have one attribute. Why doesn't it just work?

I guess the fact is that it doesn't, and we need to workaround, so the patch is fine and we should take it, but I'm still confused.

Anyway, r=me, thanks for figuring this out.

A quick bit of grepping seems to show there aren't other attributes with uppercase that we shuffle into html documents, so I guess we're OK otherwise.

Comment 9

[James Ross]

Pushed --> FIXED.