264001 - title="" attribute is ignored (parent title will be inherited).

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Cyrus Patel]

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).

Comment 1

[Martijn Wargers (dead)]

Attachment: Testcase

Comment 2

[Aaron Lawrence]

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

Comment 3

[Frank Wein [:mcsmurf]]

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?

Comment 4

[Jason Barnabe (np)]

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")

Comment 5

[Cyrus Patel]

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.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> 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?

Comment 7

[[e-mail]]

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.

Comment 8

[Boris Zbarsky [:bzbarsky]]

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.

Comment 9

[[e-mail]]

Attachment: Proposed patch

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

Comment 10

[Hixie (not reading bugmail)]

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.

Comment 11

[[e-mail]]

Attachment: Revised patch

Comment 12

[Christian :Biesinger (don't email me, ping me on IRC)]

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...)

Comment 13

[[e-mail]]

Attachment: 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.

Comment 14

[[e-mail]]

Comment on attachment 419612 [details] [diff] [review]
Revised patch

D'oh, tried to use IanN's old bugmail address :-(

Comment 15

[Ian Neal]

Attachment: Revised Testcase

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

Comment 16

[Ian Neal]

(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

Comment 17

[[e-mail]]

Pushed changeset c7ae2741a37a to comm-central.

Comment 18

[Robert Kaiser]

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.

Comment 19

[[e-mail]]

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

Comment 20

[Robert Kaiser]

So, who will file the Firefox bug? :P

Comment 21

[Oleg Torbasow]

(In reply to Robert Kaiser (:[e-mail]) 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