Last Comment Bug 264001 - title="" attribute is ignored (parent title will be inherited).
: title="" attribute is ignored (parent title will be inherited).
Status: RESOLVED FIXED
@
: testcase
Product: SeaMonkey
Classification: Client Software
Component: UI Design (show other bugs)
: Trunk
: All All
: -- normal with 4 votes (vote)
: seamonkey2.1a1
Assigned To: neil@parkwaycc.co.uk
:
Mentors:
Depends on:
Blocks: 484616
  Show dependency treegraph
 
Reported: 2004-10-12 02:56 PDT by Cyrus Patel
Modified: 2013-01-22 22:07 PST (History)
12 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Testcase (469 bytes, text/html)
2004-10-12 03:25 PDT, Martijn Wargers [:mwargers] (not working for Mozilla)
no flags Details
Proposed patch (1.84 KB, patch)
2004-10-22 13:44 PDT, neil@parkwaycc.co.uk
no flags Details | Diff | Splinter Review
Revised patch (2.49 KB, patch)
2004-10-27 15:43 PDT, neil@parkwaycc.co.uk
no flags Details | Diff | Splinter Review
Revised patch (3.22 KB, patch)
2009-12-30 13:23 PST, neil@parkwaycc.co.uk
iann_bugzilla: review+
Details | Diff | Splinter Review
Revised Testcase (640 bytes, text/html)
2010-01-01 04:04 PST, Ian Neal
no flags Details

Description Cyrus Patel 2004-10-12 02:56:57 PDT
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 [:mwargers] (not working for Mozilla) 2004-10-12 03:25:39 PDT
Created attachment 161849 [details]
Testcase
Comment 2 Aaron Lawrence 2004-10-12 08:06:20 PDT
Confirmed on 1.8a3 20040716. Should retest with a more recent build....
Comment 3 Frank Wein [:mcsmurf] 2004-10-12 11:46:31 PDT
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) 2004-10-12 18:18:01 PDT
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 2004-10-20 07:51:23 PDT
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 [:bz] 2004-10-22 09:53:37 PDT
> 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 neil@parkwaycc.co.uk 2004-10-22 10:03:41 PDT
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 [:bz] 2004-10-22 10:08:13 PDT
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 neil@parkwaycc.co.uk 2004-10-22 13:44:09 PDT
Created attachment 163066 [details] [diff] [review]
Proposed patch

This makes title="<whitespace or empty>" suppress the tooltip.
Comment 10 Hixie (not reading bugmail) 2004-10-24 16:42:34 PDT
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 neil@parkwaycc.co.uk 2004-10-27 15:43:11 PDT
Created attachment 163624 [details] [diff] [review]
Revised patch
Comment 12 Christian :Biesinger (don't email me, ping me on IRC) 2004-10-27 16:16:09 PDT
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 neil@parkwaycc.co.uk 2009-12-30 13:23:41 PST
Created attachment 419612 [details] [diff] [review]
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 neil@parkwaycc.co.uk 2009-12-30 13:26:07 PST
Comment on attachment 419612 [details] [diff] [review]
Revised patch

D'oh, tried to use IanN's old bugmail address :-(
Comment 15 Ian Neal 2010-01-01 04:04:04 PST
Created attachment 419741 [details]
Revised Testcase

Adds an extra line for the case of no title attribute.
Comment 16 Ian Neal 2010-01-01 04:09:03 PST
(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 neil@parkwaycc.co.uk 2010-01-08 15:49:25 PST
Pushed changeset c7ae2741a37a to comm-central.
Comment 18 Robert Kaiser 2010-01-09 06:32:09 PST
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 neil@parkwaycc.co.uk 2010-01-09 06:58:57 PST
It's in front-end code, so yes, this is a SeaMonkey fix only.
Comment 20 Robert Kaiser 2010-01-09 07:14:26 PST
So, who will file the Firefox bug? :P
Comment 21 Oleg Torbasow 2013-01-22 22:07:14 PST
(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

Note You need to log in before you can comment on or make changes to this bug.