User-Agent: Mozilla/5.0 (X11; U; FreeBSD 5.0; en-US; rv:1.4b;) Gecko/20030612 Build Identifier: title="" is ignored. A title="" attribute is just as if no title attribute was specified at all. The result is that the parent's title gets inherited. Reproducible: Always Steps to Reproduce: In the following html the title attribute set in the outer div will be inherited by all child elements even though the ul explicitely sets the new title to "nothing". <div title="menu"> <ul title=""> <li><a href="foo">foo</a></li> <li><a href="bar">bar</a></li> </ul> </div> This is not limited to <ul>. A title="" is always ignored. Interestingly enough, if the title is " ", then the title effectively becomes "" (no tooltip is displayed).

Confirmed on 1.8a3 20040716. Should retest with a more recent build....

It's still the case with a current trunk build. Now i wonder if this behaviour here is right or wrong, i didn't find a bug for this but also nothing in the specs. So this here is wrong? Or did i simply overlook some doc in Bugzilla/Google?

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041007 Firefox/0.10: title="": parent's tooltip title=" ": no tooltip title="test3": tooltip ("test3") IE6: title="": no tooltip title=" ": tooltip (" ") title="test3": tooltip ("test3") Opera7.54 title="": no tooltip title=" ": no tooltip title="test3": tooltip ("test3")

Frank, ignoring title="" is wrong behaviour. What moz is doing is saying title="" is equivalent to title=undefined. Whether a tooltip should still be shown when title="" is secondary. I personally would prefer/expect "" to be equivalent to nul (no tooltip). ------ I've done a little digging and I think I've found the cause for this bug: The *default* value of a title attribute is "", and there is no internal flag to differenciate this default state from an explicitely set "". Consequently title="" has no effect because nsAccessible::GetDescription() thinks that no title was set (still equal to default) when title.length is zero.

> and there is no internal flag to differenciate this default state from an > explicitely set "". That's not true. The nsIContent::GetAttr() return value indicates exactly such a difference. JS callers can use hasAttribute() combined with getAttribute() to find out whether the attribute is actually set. > Consequently title="" has no effect because nsAccessible::GetDescription() Tooltips aren't handled by nsAccessible last I checked. I don't recall what they _are_ handled by, however. Neil, do you recall?

They're handled by browser.js, and the code is somewhat weird. The tooltip code starts at the hovered element and works up to the frame root. It stops at the first element with a non-empty title or XLink title. However, it only shows the tooltip if the title has non-whitespace.

Right. So the solution is to stop at the first place that hasAttribute("title") instead, no? Then again, it's not clear to me what the right behavior is here; the spec doesn't really say.

This makes title="<whitespace or empty>" suppress the tooltip.

The title tooltip for an element should be determined by starting at that element and going up the DOM towards the root element and stopping when one of the following is found (stopping at the first one that is found): A "title" attribute in no namespace on an element in the XHTML namespace. A "title" attribute in no namespace on an element in the SVG namespace. A "title" attribute in the XLink namespace on any element that has a "type" attribute in the XLink namespace with a value exactly equal to "simple". If that title attribute is empty ("") then no tooltip is shown. Otherwise, the contents of that attribute are shown.

will this fix bug 185555? (hm... this bug does seem to be new... I'd have thought a bug like this would've been reported long ago...)

Additional changes since the previous version: * Updated for bitrot. * Moved to utilityOverlay.js as per bug 484616 and bug 234638 comment #2. * Removed XLink support as that's being dropped from core anyway.

Comment on attachment 419612 [details] [diff] [review] Revised patch D'oh, tried to use IanN's old bugmail address :-(

Adds an extra line for the case of no title attribute.

(In reply to comment #13) > Created an attachment (id=419612) [details] > Revised patch > > Additional changes since the previous version: > * Updated for bitrot. > * Moved to utilityOverlay.js as per bug 484616 and bug 234638 comment #2. > * Removed XLink support as that's being dropped from core anyway. With this patch applied I get: no title: tooltop ("menu") title="": no tooltip title=" ": tooltip (" ") title="test3": tooltip ("test3") If this is correct, then r=me

Pushed changeset c7ae2741a37a to comm-central.

Will a new bug be needed to get this in fixed in Firefox as well, or do they do things differently? If a new bug is needed, we should at least care that it's filed.

It's in front-end code, so yes, this is a SeaMonkey fix only.

So, who will file the Firefox bug? :P

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #20) > So, who will file the Firefox bug? :P I’ve done this here - https://bugzilla.mozilla.org/show_bug.cgi?id=833680