Closed Bug 264001 Opened 15 years ago Closed 10 years ago

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

Categories

(SeaMonkey :: UI Design, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
seamonkey2.1a1

People

(Reporter: cyp, Assigned: neil)

References

Details

(Keywords: testcase, Whiteboard: @)

Attachments

(2 files, 3 obsolete files)

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).
Attached file Testcase (obsolete) —
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?
Whiteboard: @
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")
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
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.
Attached patch Proposed patch (obsolete) — Splinter Review
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.
Attached patch Revised patch (obsolete) — Splinter Review
Assignee: nobody → neil.parkwaycc.co.uk
Attachment #163066 - Attachment is obsolete: true
Status: NEW → ASSIGNED
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...)
Attached patch Revised patchSplinter Review
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.
Attachment #163624 - Attachment is obsolete: true
Attachment #419612 - Flags: review?
Attachment #419612 - Flags: review? → review?(iann_bugzilla)
Comment on attachment 419612 [details] [diff] [review]
Revised patch

D'oh, tried to use IanN's old bugmail address :-(
Attached file Revised Testcase
Adds an extra line for the case of no title attribute.
Attachment #161849 - Attachment is obsolete: true
(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
Attachment #419612 - Flags: review?(iann_bugzilla) → review+
Pushed changeset c7ae2741a37a to comm-central.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Component: Layout → UI Design
Product: Core → SeaMonkey
QA Contact: layout → ui-design
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
Blocks: 484616
Target Milestone: --- → seamonkey2.1a1
(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
You need to log in before you can comment on or make changes to this bug.