494074 - Hovering over channel tab always show tooltip for active tab

Status: RESOLVED FIXED

(Other Applications Graveyard :: ChatZilla, defect)

Description

[Stefan [:stefanh]]

ChatZilla 0.9.84 [SeaMonkey 2.0b1pre/20090519003252], mac os 10.5.6

STR:

1) Have a couple of channels open (A, B, C, ,D)
2) Be in channel B
3) Hover over channel D's tab

Expected results: Tooltip for channel D appear
Actual results: Tooltip for channel B appear

--> No matter what channel tab you hover, the only tooltip appearing is the tooltip for the active tab.

Comment 1

[James Ross]

We don't provide any tooltips for the tabs, so this is some core code doing something stupid. Anyone know how we can tell it to get lost?

Comment 2

[Stefan [:stefanh]]

(In reply to comment #1)
> We don't provide any tooltips for the tabs

extensions/irc/xul/content/static.js#3219: 'tb.setAttribute("tooltip", "xul-tooltip-node");'

Removing that line makes the tooltip(s) go away. I'm unsure of why it gets set there and haven't really investigated if the removal impacts other stuff. It's been there for some time and it obviously didn't caused tooltips to appear in 1.8, so maybe some core changes made it start "working"?

Comment 3

[James Ross]

The onpopupshowing handler for the tooltip element returns false (unless core's broken something) for the tabs, and we don't even put any elements into the <tooltip> element, as far as I can see - I'm also sure nothing has changed anywhere near this recently either.

Can someone screenshot it?

Comment 4

[Stefan [:stefanh]]

Attachment: screenshot

In this screenshot I hover over the #documentation tab - the active channel/tab is #maildev. This is with ChatZilla 0.9.84 [SeaMonkey 2.0b1pre/20090519003252] (Mac OS 10.5.6)

Comment 5

[Stefan [:stefanh]]

fwiw, I installed cz on a shiretoko build (from May 7) and the same thing happens there.

Comment 6

[James Ross]

Could document.title be getting automatically exposed by an attribute in trunk? If you want to try
  /eval document.title = "Foo"
and then hover over tabs (the title will be reset by ChatZilla on tab switching and people joining/leaving, so pick a less active channel to try from).

Comment 7

[Stefan [:stefanh]]

Yeah, looks like it. Doing /eval document.title = "Foo" gets me "Foo" in all tooltips.

From your comments I get the impression that we have 2 issues here:

1) You don't really want channel tabs to have tooltips.
2) On mac, the active tab's tooltip text is displayed for all channel tabs (I think tooltips are displayed on other OS as well, but the text/label reflects the active channels title).

Comment 8

[James Ross]

Well, it's not really displaying "the active tab's tooltip text", as there is no such thing; it is displaying the window's title because some ancestor element of the tabs has a "title" attribute reflecting document.title (onTooltip, in handlers.js, looks up the ancestory of the hovered element to find the text).

Could this be as old as 2008-08-17? Bug 118704 made a large number of changes to document.title and it looks very much like it stores it in a "title" attribute on the root content element (not too sure what this in DOM, but I'd guess it is document.documentElement, i.e. the <window>).

Comment 9

[Stefan [:stefanh]]

(In reply to comment #8)
> Well, it's not really displaying "the active tab's tooltip text", as there is
> no such thing;

Right.
 
> 
> Could this be as old as 2008-08-17? Bug 118704 made a large number of changes
> to document.title and it looks very much like it stores it in a "title"
> attribute on the root content element (not too sure what this in DOM, but I'd
> guess it is document.documentElement, i.e. the <window>).

Looks like it:
ChatZilla 0.9.83 [SeaMonkey 2.0a1pre/20080817002501] doesn't display any tooltips at all.

ChatZilla 0.9.83 [SeaMonkey 2.0a1pre/20080818002446] has the reported issue.

Comment 10

[Stefan [:stefanh]]

> ChatZilla 0.9.83 [SeaMonkey 2.0a1pre/20080817002501] doesn't display any
> tooltips at all.

(On channel tabs)

Comment 11

[:Gijs (he/him)]

So is this a bug or a feature of the work done in bug 118704, and do we need to workaround or should we attempt to correct the bug/feature?

Comment 12

[James Ross]

The whole idea of bug 118704 was store the title in the DOM, rather than having an internal variable separately, so in that sense it was intentional (though I didn't see any discussion or "thought" about this storage in XUL). We're just unfortunately looking up the ancestor elements for anything with a "title" attribute; we can exclude the documentElement in our search easily enough, it was never going to have a real title.

Comment 13

[James Ross]

Attachment: Avoid showing the title attribute from the document element

Comment 14

[:Gijs (he/him)]

Comment on attachment 394748 [details] [diff] [review]
Avoid showing the title attribute from the document element

r=me, assuming that's been verified to fix it (and goodness me what a silly bug)

Comment 15

[James Ross]

Checked in --> FIXED.