Closed Bug 45375 Opened 24 years ago Closed 18 years ago

SeaMonkey-only bug: Long tooltips should wrap instead of being cropped (multiline tooltips)

Categories

(SeaMonkey :: UI Design, enhancement, P3)

enhancement

Tracking

(Not tracked)

VERIFIED FIXED
seamonkey1.1beta

People

(Reporter: bcortez, Assigned: csthomas)

References

(Depends on 1 open bug, )

Details

(5 keywords, Whiteboard: DO NOT COMMENT! THIS IS NOT A FIREFOX BUG!)

Attachments

(8 files)

Description:
When hovering the mouse over the image, the tooltip (from the TITLE Tag) does 
not display properly. It fails in the following ways:

1. It doesn't wrap in any fashion to accomodate long strings.
2. It fails to remain within the boundaries of the screen and clips.
3. It doesn't behave as the actual browser tooltips in that if the mouse is on 
the left hand side of the screen the tooltip will appear on the right, if the 
mouse is on the right, the tooltip will appear on the left, etc... 
4. The only time the "entire" message is displayed is if the mouse is against 
the far right side of the screen (even then it still clips the TITLE string of 
its too long).

------
Reproducibility: 
Every Time

------
Steps to Reproduce:
1. Bring up the offending page
2. Move the mouse over the image containing the long TITLE attribute
3. The TITLE attribute string will appear as a "tooltip"

NOTE: Follow hyperlinks on URL specified above to see actual screenshots of 
Mozilla vs. Microsloth IE4

------
Expected Results:
Debatable really.  It should wrap the text in some manner and always display it 
within the available screen width.		

------
Additional Information:
This bug is a result of testing the recent fix for bug 27828.  The browser 
tooltips seem to work as expected, just the HTML rendering of the TITLE 
attribute of an element seem to be affected.

------
Severity:
Normal
Depends on: 27828
On linux the tooltip is rendered at 0x0 with no word wrap at all. Build
2000072608 Linuc (RH 6.2)
setting bug status to new
Status: UNCONFIRMED → NEW
Ever confirmed: true
over to qa owner of things image-related... elig!
QA Contact: sairuh → elig
Old summary: (Build ID: 2000071120) The image, the tooltip (from the TITLE Tag)
does not display properly.

Changing summary.
Summary: (Build ID: 2000071120) The image, the tooltip (from the TITLE Tag) does not display properly → tooltip from <img>'s title attribute displays badly
Blocks: 59743
I am running M18-2000101014 on Win2k and M18 on Linux: on both versions <IMG>'s
ALT attribute does not display (i.e. as a tooltip) when the image is loaded.
Some websites use ALT attribute as a help for images that have been already
loaded. Don't know if this is to be classified as a RFE or a bug, but in any
case I think a tooltip should be displayed.
QA Contact: elig → sairuh
Netscape nav triage team: per Alec Flett's pre-triage recommendation, this 
bug is nsbeta1-.
Keywords: nsbeta1-
Marking nsbeta1- bugs as future to get off the radar
Target Milestone: --- → Future
QA Contact: sairuh → tpreston
*** Bug 78692 has been marked as a duplicate of this bug. ***
Though this isn't a huge bug by any means, I think it has become somewhat more
important now that it has been decided for good that images' ALT attributes will
not be shown by Mozilla as tooltips.  (I forget in which bug report this was
debated and decided.)

I find myself more and more using the TITLE attribute as a way to add
non-crucial information to a page without adding content clutter.  I always plan
for the fact that the TITLE attribute will have no effect in older browsers, but
when longer TITLE strings get truncated rather than wrapped, it just makes the
pages using it look broken.  

This one gets my vote!
Since I've duped some things so that bug 47078 covers the general problem of 
newlines not being stripped from attributes, I'm turning this into an RFE to 
cover the problem of tooltips disappearing beyond the edge of the screen.  
Adjusting summary accordingly and removing 59743 as a dependency; I'll dupe 
that bug to this one.
No longer blocks: 59743
Summary: tooltip from <img>'s title attribute displays badly → [RFE] Tooltips should wrap and not disappear off screen.
*** Bug 59743 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
*** Bug 106382 has been marked as a duplicate of this bug. ***
Depends on: 116142
Isn't bug 57599 of dupe of this bug?
*** Bug 57599 has been marked as a duplicate of this bug. ***
Adding/changing keywords, dependency, platform and OS from duplicated bug 57599.

BTW severity of duplicated bug was 'normal', this bug is just 'rfe' - what about
changing it too?
Blocks: advocacybugs
OS: Windows NT → All
Hardware: PC → All
*** Bug 116142 has been marked as a duplicate of this bug. ***
Adding access and html4 keywords as per duplicate bug 116142.
Keywords: access, html4, nsbeta1
nsbeta1- per Nav triage team, ->1.2
Keywords: nsbeta1nsbeta1-
Target Milestone: Future → mozilla1.2
adding self to cc list
This bug concerns tooltips that result from the TITLE tag. This bug does not
include chrome tooltips.
No longer depends on: 116142
*** Bug 116142 has been marked as a duplicate of this bug. ***
Is XP Apps: GUI Features the right component for this bug?
I am having the same problem as Kevin Cook.  I started using Title attributes to
provide additional information on elements in a page.  It works great in IE, but
Mozilla truncates the text rather than wrapping it.  Got my vote.
*** Bug 152530 has been marked as a duplicate of this bug. ***
*** Bug 153168 has been marked as a duplicate of this bug. ***
Voting for this to be fixed. It breaks the usability on some sites, such as
www.texturizer.net.
*** Bug 155095 has been marked as a duplicate of this bug. ***
*** Bug 155724 has been marked as a duplicate of this bug. ***
Testcase behavior: In Mozilla (2002070813 WXP) the tooltip's text is severely
limited. There's a short snippet, then an ellipsis. IE6 renders the tooltip
nicely, softwrapping the text and honoring newlines.

I think it's important that 1. the full text is made visible through some means
(other than view source, of course) regardless of any limitation on the viewer's
screen, 2. newlines in the value of the title are rendered as newlines in the
tooltip, and 3. the ellipsis is only used when absolutely, positively necessary.
(It's stupid to cut it off at x number of characters when there's plenty of room
on my screen to accomodate at decent bit more text than that.)
Keywords: html4testcase
*** Bug 158880 has been marked as a duplicate of this bug. ***
*** Bug 159785 has been marked as a duplicate of this bug. ***
The [RFE] in the summary is inaccurate, since this bug's severity is (correctly)
set to normal. This isn't an enhancement, it's a problem-the TITLE attribute
(W3C HTML 4 recommendation) is not properly displayed.
Keywords: html4
Summary: [RFE] Tooltips should wrap and not disappear off screen. → Tooltips should wrap and not disappear off screen.
Hmmm. Not much activity in this bug anymore. Tooltips are becoming increasingly
pervasive. Let's make them work properly in Mozilla.
Another highly visible Mozilla usability flaw that just sits around gathering
dupes, eh?

I've even gone to the trouble of writing a fairly large Mozilla-only Javascript
(http://nik.angrycake.com/js/moz_fudge.js) to handle titles on elements because
I was so sick of having to switch to IE just to read even *my own* web page.

Trying to get other people to use it - despite that it involves pasting a single
<script src=> into the body of a page - is like talking to a brick wall. After
all, 'IE and Opera can do it by default, so why bother? Mozilla is obviously
just a badly written browser that will never take off.'

It's bugs like this that stop Mozilla getting a decent userbase, and stop me
giving up IE altogether. This bug is more than *two years old*, and most of the
work (the current tooltip implementation) is already there. How does that look?
Careless, inefficient. Bad.
Ive also noticed Tooltips dont unfold into view in windows 98/ME and they don't
fade into view on 2k and XP.
See Bug 166518
Instead of wringing hands, it would be great if you would write a patch.
Andrew, maybe he doesn't know how to write patches yet? Maybe he's just
frustrated because this bug is very obvious on many sites, it has 28 votes, it
has 12 duplicates, it is assigned to ben@netscape.com, it has a target milestone
set to mozilla1.2alpha, a priority of P3, and still nothing has happened in over
two years?

I for one understand him. It breaks my site too. Sorry about the spam, but this
bug really needs to be fixed. If anything, the target milestone should be changed.
I apologize for the spam as well (I am even off topic) but I also feel the need
to jump in on this comment, as this bug breaks my site as well.  I am getting
really tired of the "write a patch then" attitude in the free software
community.  Just because anyone /can/ contribute to a project, doesn't mean the
project developers shouldn't try to meet the needs of their users.  By "whining"
in this bug, I am not trying to disparage Mozilla or it's developers, I am
merely hoping to attract some badly needed attention/priority to what I feel is
an important issue, this bug.  Incidentally, since moving to Linux, I would thus
far have needed to write a patch for Nautilus (folder searching), XWindows
(nv+dvi), Gnome (clipboard), Evolution (sound notifications), Gedit
(search/replace), Mozilla, etc, etc.  Even if you do happen by some freak chance
to be a developer, as am I, Mozilla and the rest of these are all very large
projects which take considerable developer expertise and ramp up time in order
to code for.  I could spend months learning Mozilla tool tip code in order to do
something that might take a Mozilla developer half an hour to fix.  I just can't
contribute that much time to /every/ project for which I need fixes.
The Mozilla source is, for someone who's never looked at it before and has no
idea about where to begin, a horrible impossible mess. 230MB of files with
little in the way of documentation is really not fun.

From what I've seen, it will also require me to be able to compile all the cpp.
Now, I've been trying to do this, off and on, for simple embedding purposes, but
I've yet to manage an installation of Cygwin, because the connections drop with
alarming regularity and the installer is ****.

So, if someone gives me good, fairly specific pointers (I've found lots to do
with tooltips, but little that appears to do anything with truncating text), I
may be able to write a patch. But I won't be able to compile (and therefore
test) it.

I think it's better that someone who has a clue fixes it, rather than demanding
that end-users who show interest in a rotting, important bug do it themselves.

I'd apologise for the spam, but I'm not sorry. I'm angry; shouting down users
who want what's best for Mozilla but can only help in small ways (eg, by
bringing renewed attention to very stale bugs), is good for no-one.
*** Bug 177600 has been marked as a duplicate of this bug. ***
*** Bug 177597 has been marked as a duplicate of this bug. ***
Attached image Example
Image of what tooltips do in Opera and IE and how Mozilla gets it realy wrong
Keywords: mozilla1.0mozilla1.3
*** Bug 183706 has been marked as a duplicate of this bug. ***
This is a major usability issue. It has many dupes and votes. Requesting 1.3b
blocking.

pi
Flags: blocking1.3b?
Flags: blocking1.3b? → blocking1.3b-
Although it was taught and given when I asked by Japanese Bugzilla,

http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=2806#c4
>Windows$B$N>l9g$O$3$N%a%C%;!<%8$rAw?.$7$F$*$/I,MW$,$"$j$^$9!#(B
>(In the case of Windows, it is necessary to transmit this message.)
>
>TTM_SETMAXTIPWIDTH
>
>TTM_SETMAXTIPWIDTH
>    wParam = 0;
>    lParam = (LPARAM)(INT) iWidth;
>
>http://www.kumei.ne.jp/c_lang/sdk3/sdk_260.htm

Does it become the hint which solves a problem?
*** Bug 186362 has been marked as a duplicate of this bug. ***
*** Bug 186362 has been marked as a duplicate of this bug. ***
I just tripped over this bug when I added the TITLE attribute to tags on my pages.
In programs lengthy bubble help texts are getting more and more popular.
Consequently the user is expecting them on web pages as well.

I have to concur with 'pi' that this bug is a major usability problem and
should be resolved with release 1.3.

Therefore this bug gets my vote!
Ben,

this bug is assigned to you. The target milestone passed. Is there hope?

pi (no quotes needed)
*** Bug 189178 has been marked as a duplicate of this bug. ***
*** Bug 189889 has been marked as a duplicate of this bug. ***
*** Bug 190618 has been marked as a duplicate of this bug. ***
Mh, more dupes coming in. 

Could anybody who is in charge please change the milestone to a more appropriate
target and add the keyword clean-report. Thanks.

Hey, I have some more votes left that I want to cast for this bug :-)
OK there is no point haveing 1.2a as a milestone when its been and gone.
Target Milestone: mozilla1.2alpha → Future
Let's reflect a moment on the history of this bug.  I submitted it on July 13, 
2000 (technically the last century).  Here we are 2 years, 6 months, and 23 
days later and it currently has 19 duplicates, 41 votes, and nothing, I repeat, 
NOTHING has been done to address this issue.  I am a patient man, but this is 
unacceptable.  I have seen less visible bugs, lower priority bugs, and 
(frankly) eye-candy related "bugs" come an go in this timeframe.  

Also, the response from the Mozilla community to "fix it yourself then" is also 
totally UNACCEPTABLE.  If the Mozilla project expects to compete in any type of 
fashion in the corporate world (and let's face it, that is where the money is 
folks) then it MUST address basic functionality issues such as this and others 
in this same state.  

I mean if Opera and every other resonable browser on this planet can get 
tooltips right, then what the #$@#$ is the problem here?  I constantly get 
calls and questions from clients asking my opinion of Mozilla/Netscape and I 
must reluctantly reply that it is NOT production-level enough to use in a 
corporate environment.  They always respond with distain and simply move to 
MSIE with the "well, if they can't get this right, what else is hiding under 
the covers" attitude.

Those are the facts out here in the real world guys and gals. Base 
functionality goes a long way from a PR perspective. 

(Well deserved and long overdue rant on this bug from it's creator)
> Also, the response from the Mozilla community to "fix it yourself then" is 
> also totally UNACCEPTABLE.  If the Mozilla project expects to compete in any 
> type of fashion in the corporate world (and let's face it, that is where the 
> money is folks) then it MUST address basic functionality issues such as this 
> and others in this same state. 

Mozilla is not a corporate product. It is a community project and as such it is
not in competition with anything other than itself.  Regardless of whether or
not "the corporate world" makes use of it, mozilla development will continue for
as long as the community is interested and at the rate the community contributes.

Mozilla developers are not corporate employees.  They are volunteers and as such
they do not contribute to mozilla for the sake of making money.  Regardless of
"where the money is," mozilla developers will continue to contribute for as long
as they are interested and at whatever rate they desire.

Your rant is better directed towards Netscape or some other corporate entity. 
If they "expects to compete in any type of fashion in the corporate world then
[they] MUST address basic functionality issues such as this."  But if they do
fix the problem in their version of the code, please remember to put on a nice
big smile and ask as politely as you can that they contribute their work (for
which they have *paid* good money) back to the mozilla project even though they
wont get or make a cent for doing so.
No longer depends on: 27828
> Mozilla is not a corporate product. It is a community project and as such it
> is not in competition with anything other than itself.

Even community projects do compete. They compete for being deployed.

What good is a software that is not being used?
RE: Ian Pottinger

Your statement, "Mozilla is not a corporate product" is true.  However, the 
foundation codebase being built by the generous Mozilla community IS being used 
a corporate product (Netscape) as well as being eyed for other corporate 
products into the future.  Therefore, that dependency makes it a corporate 
product whether you care to admit that fact or not.  Keeping your eyes closed 
to this is simply naive.

Your statement, "Mozilla developers are not corporate employees.  They are 
volunteers and as such they do not contribute to mozilla for the sake of making 
money" is also naive.  True they are not Mozilla corporate employees, but I'm 
willing to bet that the VAST majority of Mozilla developers work for (or will 
work for) some professional corporate entity.  As such, the same committment to 
quality and dedication to the product should apply.  

Your statement, "Your rant is better directed towards Netscape or some other 
corporate entity" is also misdirected.  Who do YOU think is propping up the 
Mozilla product development?  It's not Microsoft, it's not the community itself 
(the $$ donations to Mozilla do not constitute the bulk of 
development/admin/harware costs). The work, yes, is provided by the community.  
However, the daily administration costs and hardware are supplemented by 
AOL/Netscape an many other corporate entities are they not?  Do ALL the Mozilla 
developers work from their homes, or do they use corporate facilities, 
educational facilities, etc?

The argument, "...if they do fix the problem in their version of the code, 
please remember to put on a nice big smile and ask as politely as you can that 
they contribute their work (for which they have *paid* good money) back to the 
mozilla project even though they wont get or make a cent for doing so."  I will 
put on a smile, a smile I've waited almost 3 years to unwrap. Also, 
don't "they" HAVE to re-contribute it to the community codebase since this is 
an open source development project governed by those rules?

I've been a user of web browser since NCSA Mosaic 0.9, I've seen browsers come 
and go over this timeframe.  The ones that have survived were the ones that 
produced a solid base of functionality.  In the world of free commodities, 
basic functionality should be a given....period. I get a physical ache in my 
heart every time I have to tell people who ask that after 5 years of 
development, that what they percieve as a simple browser is not production-
level.  Then to see them turn to MSIE and never (NEVER) look back.


Look, I don't want to spam the recipients of this buglist with more personal 
rankor. If I didn't care, then I wouldn't be so passionate about this issue. I 
simply want some piece of basic functionality fixed that has lain dormant for 
almost 3 years with no forseeable action being taken to address the issue. 

(I apologize to all recipients, but I just couldn't hold it in any longer)


Hey Ben, stop talking about cars on your blog for a few minutes fix this bug so
everyone can stop fighting about whether or not Mozilla should cater to some
particular audience over another. And Ian, did you notice what Ben's email
address is? What's that about corporations not driving the development of Mozilla?
Requesting 1.3 blocker.
Flags: blocking1.3?
Flags: blocking1.3? → blocking1.3-
Is there anything left on this bug?  Tooltips were fixed a while back to remain
on-screen properly and also to shift to the left until there's room instead of
just flipping to the left of the mouse.  The debate over newline in tooltips
rages on in bug 67127.

Since this bug has gotten quite off-topic and diluted, I'm marking it as a dupe.
 This does not give you the right to start bitching over in the other bug now.

*** This bug has been marked as a duplicate of 67127 ***
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
With BuildId 2003020420 Xft on Red Hat Linux 8.0+ I still see a tooltip that is
"clipped" (with "..." added at the end) in attachment 90744 [details] example.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Yes, exactly. See comment #30. Tooltips need to wrap to show the contents of 
the title attribute. They are currently clipped.
Dean,
it's quite clear that this bug is no dupe of bug 67127:

This bug is about wrapping a long tooltip text no matter if it
contains any newlines.
Blocks: majorbugs
Changing summary because tooltips no longer disappear off screen (as pointed out
by comment 62). Old summary: "Tooltips should wrap and not disappear off
screen." This bug is certainly still valid - bug 67127, while related, deals
with a different matter.
Summary: Tooltips should wrap and not disappear off screen. → Long tooltips should wrap instead of being cropped (multiline tooltips)
*** Bug 198197 has been marked as a duplicate of this bug. ***
Flags: blocking1.4a?
Flags: blocking1.4a? → blocking1.4a-
Keywords: mozilla1.3
Still a major usability issue, setting major and requesting 1.4 blocking. This
is kind of dataloss -- you cannot access information from web pages.

pi
Severity: normal → major
Flags: blocking1.4?
Severity: major → normal
hi!

Somebody has reset the severity to normal. It seems, they
are ignoring this bug(ger).

Cheers,
Daniel
Re: change of severity to normal

Here's the source of the email I got when this happened: 
http://home.golden.net/~duey/bugzilla.txt  It shows the email of who did it.  I
wanted to add the source headers to prove that I didn't forge the email.

I believe whoever did it should've explained why he/she switched it back to normal.
Who cares about your email. You can click on the "View Bug Activity" link easily
enough to find out who changed what to what and when. I think it's about time
someone add to the status whiteboard not to add to the discussion unless it's
because you are implementing the fix.
RE: Paul Baker of entry #71.

Paul, there is no need to flame him on that aspect.  Simply emailing him 
directly would have sufficed.  However, being the original bug reporter, I feel 
an answer to his question is warranted.  I think that if the status of a bug is 
changed, a note describing WHY should be entered as well.

this is a long, long, long standing bug.  It does result in loss of data to the 
user. Yet, it get continually ignored and passed along in the builds...

It now has 52 votes, 23 duplicates, and has lived for over 2 years and 8 months 
now.  

Maybe in a few months time I'll be able to celebrate it's 3rd birthday?


Severity: normal → critical
Keywords: dataloss
xah@myrealbox.com, please use the Bugzilla keywords wisely. There is no dataloss
caused by this bug.
Keywords: dataloss
Example of information that is not reachable due to this bug:

http://www.anwb.nl/servlet/Satellite?pagename=OpenMarket/ANWB_verkeer/PopupVerkeer&regio=randstad&rubriek=File_nieuws_regio_randstad

When there is a trafic jam, exclamation marks are added to the map. Hovering
above this exclamation marks shows tooltips with detailed information. However,
due to this bug the most important part of this information cannot be read.
Please, do not spam there. This bug hides information from user but it isn't
dataloss. Dataloss keyword should be added only if user loses important
information such as his/her input or complete web page.
Flags: blocking1.4? → blocking1.4-
Keywords: useless-UI
The owner of Deviantart.com (the site the example is from) "Jark" is a Mozilla
user, and he now uses some sort of script in the thumbnails section so all the
data can be seen, even in mozilla, i wonder if this could be for mozilla?

go look http://www.deviantart.com/thumbnails.php
Re comment #76: Those 'tooltips' on deviantart.com are actually made in DHTML,
with onmouseover/out handlers on the thumbnails, that show/hide
absolutely-positioned DIVs.  We're investigating a similar method at OEone for
ANYWHERE; it gets around not only this bug, but also the fact that IE doesn't
acknowledge the TITLE attribute on many elements.

It's a handy strategy for making cross-browser, eye-candy tooltips, but it's not
one that can be integrated into Mozilla.  It's the sort of thing each website
must do on their own.  (Unless a standard for "tooltips supreme" someday appears
from the W3C, but even then, support for standards isn't a high priority at some
companies.)
The problem with a client-side DHTML approach is that it is not 100% when form 
fileds are in this mix.  The DIV (on many browsers) doesn't (and can't) appear 
as a layer above for fields.  This make the page look broken at best.  The 
solution for Mozilla is to fix the tooltip handling code in the browse itself.
*** Bug 206014 has been marked as a duplicate of this bug. ***
Is it really a XPFE-only issue. Firebird seems to suffer from the same bug and I
thought it was not XPFE-based.
Summary should be changed to:
Long tooltips should wrap instead of being cropped, regardless if it contains
newlines or not.
Just 2 more cents into an already overflowing pot...

I think, especially with the "War on IE", that Moz would be doing what it could
to make sure that pages in IE and Mozilla display almost identically.  This is a
great example of where that doesn't happen.

MS used to have a team of engineers (and they may still) that used to check how
a page displayed in other browsers (mostly NS4 during that timeframe) and tweak
their rendering until it looked identical.

If for no other reason, this bug should be fixed so that the "IE superiority"
camp has one less flag to wave over Mozilla's head.

I realize, what with RC1 coming out yesterday, that it's too late for 1.4.  It
shouldn't have to wait much longer.
*** Bug 209455 has been marked as a duplicate of this bug. ***
I'm tired to see this incredible bug still alive.
I would like to file the formal request of assigning this bug 
to other folks.
IMHO, UI bug like this should have top priority, unfortunately 
as a sloppy VB programmer i can't afford to bugfix by myself, 
but i'm pretty sure there are folks here around with much more
skill that would take no more than few hours to get finally rid of.

Is it just my copy of Opera 7.03, or does it not wrap the tooltip in attachment
90744 [details]?
> Is it just my copy of Opera 7.03, or does it not wrap the tooltip in
> attachment 90744 [details]?

My copy of Opera 7.11 (Windows) wraps the tooltip but it ignores the newline
characters. It does a funky hanging ident thing too.
*** Bug 215372 has been marked as a duplicate of this bug. ***
Fixing this is not too difficult, is it?
+1 vote to fix it
Flags: blocking1.5?
Flags: blocking1.5? → blocking1.5-
I'm interested in attempting to fix this bug...  I'm a competent C/C++
programmer with no experience with the Mozilla code base, so I'd appreciate it
if someone could point me to the part of the code (file and lines) where
tooltips are handled, and I'll take a look.
fixing severity. 
Severity: critical → trivial
I'm starting to get the feeling that the people in charge of these things aren't
just neutral about this bug, they really would like to see to it that it
continues to go unfixed as long as possible.  I find this quite perplexing,
considering the obvious community interest in seeing it fixed (73 votes at the
time of this post).  

I challenge all of you stop-complaining-and-fix-it-yourself folks to take a
minute or two out of your day to point out where (file and approximate line
numbers) this bug is so that I can take a look at it and attempt to fix it.  I
don't think that's an unreasonable request from a newbie, considering the size
of the Mozilla codebase.


perhaps this is a good place to start looking ..

http://lxr.mozilla.org/mozilla/source/layout/xul/base/src/nsXULTooltipListener.cpp
See also bug 218223, same bug for Firebird.
How come this bug has trivial severity?

I believe this bus is not just a cosmetic problem like innocent typo,
but a major(or at least, minor) loss of function which hides much information
of many existing web sites away.
Asa, it would be nice if you could comment your change, this is not about
cosmetics. This here is a major loss of function, it makes the title attribute
unaccessible to Mozilla users. By this it also violates HTML 4
(http://www.w3.org/TR/html401/struct/global.html#h-7.4.3). So this is by no
means trivial, it is major usability and accessibility issue.

pi
Blocks: html4.01
Severity: trivial → major
3 years, 1 month, 23 days and still kicking.  Is there a prize for the longest 
standing UI dataloss bug?
It appears Asa was trying to punish us for the person who put "critical"
severity on this bug. But actually the only correct severity for this bug is
"minor" because there is a loss of function involved (data is missing from the
title tooltip) but an easy workaround is present (view source).

Minor	minor loss of function, or other problem where easy workaround is present

Let's please not change that anymore.
Severity: major → minor
"View source"???? This can't be true! You're joking! With this solution I check
each page with the source because I don't know wheter there is information I can
not see. There are people out there that do not know how to see the source (and
when they see the source ...).
For web designers including me, the workaround of this bug is by no means easy.
The only workaround I can think of is using JavaScript with introducing 
absolute-positioned <DIV>. It will cost me several hours and still, such 
pseudo-tooltips are far from perfect, making text browsers and text-readers 
useless.

Letting the visitors view the page source is out of the question of course, 
and that's why this bug is collecting these votes.

"Easy workaround" should be used when if you add no more than
10 words in my site and everything works perfectly.
Please let us not spam this bug more, it just decreases the chance of it getting
solved, since developers or those willing to solve the bug do not want to read
through all the offtopic discussion to find information important to them.
Please refrain from commenting unless you have to add something that helps with
getting the bug fixed. 

Developers, please refrain from provoking more spam by setting the priority too
low or giving less the helpful instructions for workarounds. This is something
many people care about.

So instead of bitching about the priority field it would be useful to come up at
least with a design how tooltips *should* work without breaking their use in
other parts of the program.

Obviously, it is not sufficient to increase the maximum tooltip length because
the text can always be long enough for not fitting on a single line on the screen. 
So we need a wrapping strategy. What should the width used for wrapping be? What
if there is no white space to brake on? Should the text be left aligned or
centered? Should embedded line breaks be respected?

Konqueror nicely formats the tooltip for the testcase and also respects embedded
line breaks. It formats the text as centered lines within the tooltip window.
Attached image Tooltips in IE
I investigated how tooltips work in IE6.0(WinXP).

* The maximum width of tooltips is 300 pixels fixed, no matter the size of the 
parent browser is, no matter how long the content is.

* Hyphnations and word-wrapping are done completely.

* Tooltip text is always aligned to the left, even if the titled elemnt itself 
is aligned to the right or centered (at least in English)

* The actual width of tooltips can be less then 300px, to fit the width of the 
rendered content. (See the attachment image file)

* If the tooltip is really long and the height of the tooltips is larger than 
the screen height, it simply overflows; Still it never inflates horizontally.

As for Winodows, an API called DrawTextEx can do these kind of text formatting 
automatically. Sorry I have no idea what the alternative is in Mozilla. 

In current Mozilla/Windows, the max width of tooltip seems to be approx. 
400px. Anything longer than that is clipped.

I guess the behavior of IE is quite adequate in most cases.
There is no discussion here, this bug should be "major" and should block 1.5 
final release. Please change back it to major.
Flags: blocking1.5- → blocking1.5+
Paolo Marani: Please, don't set blocking status, it's drivers job.
Flags: blocking1.5+ → blocking1.5-
Sorry guys, i believed the UI would prevent me to change any 
flags by myself because missing rights. 
Anyway, i wont pollute this list anymore, but i would like to know
how can i convince drivers to take into account this bug as top 
priority for next moz release. Consider this please:

1- 74 votes looks like huge user complain.
2- It's somewhat a dataloss (view source is not a viable option)
3- Filed 3 years ago !!

Regards,
Bug 216592 seems to be closely related.
Flags: blocking1.4a-
Flags: blocking1.4-
Flags: blocking1.3b-
Flags: blocking1.3-
See also Bug 221320
Flags: blocking1.6b+
Flags: blocking1.6+
ondrej: read comment 106
Flags: blocking1.6b+
Flags: blocking1.6+
Status Update:
88 votes,
3 years 4 months and 22 days old,
no progress,
not considered real dataloss,
and an unacceptable workaround (view source!!)

Nice :)

Please, do not agree there. And better, write a patch ;)

2drivers: please, add DO NOT SPAM in Status Whiteboard.
It would seem the user community has spoken on this one.  :)  Now, are there 
any technical or other roadblocks to doing this for 1.6?
Since I am the original reporter, who has waited over 3 years, and have to deal 
with the daily corporate and cuatomer questions on supporting Mozilla, and this 
tooltip issue, I think I have the right to complain a bit.  The response "then 
write a patch" is completely in appropriate as well. If I could write a patch, 
don't you think I would have done that 3 #$@#$ years ago!!!
And it's assigned to:

bugs@bengoodger.com (Ben Goodger (I don't read bugmail))

Even better, talk about the kiss of death.
bored of this now
Based on the lack of activity in this bug, the reality that this bug is not
currently owned by Ben Goodger should be reflected in him not having formal
ownership of the bug.
Assignee: bugs → guifeatures
Status: REOPENED → NEW
I wonder if one of the authors (who are they) that implemented the tooltip
feature (and the related pupup functions) could give ideas where to start
looking and how to best tackle this bug. 
Johann: check out the patches attached to related bug 67127.
Proposal for how to better handle this bug: it seems that many are interested to
help solving the bug, but the complexity of the code and lacking knowledge of
details in the code prevent this until now. Since bugzilla is not the right
place for lengthy and detailled discussions I suggest that all interested
developers have a look at this thread to discuss how to proceed and take it from
there: http://forums.mozillazine.org/viewtopic.php?t=38949
Taking from guifeatures@xpapps.bugs
Assignee: guifeatures → bugzilla
Accepting - I have posted a patch on bug 67127 that possibly fixes this bug
Status: NEW → ASSIGNED
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031201
Firebird/0.7+

I patched popup.xml inside MozillaFirebird/chrome/toolkit.jar using the patch in
bug 67127.  The patch does indeed fix the wrapping problem in the limited cases
I tried.
Depends on: 228100
Depends on: 228673
Ian why not just spin off a patch that only fixes the wrapping problem from the
patch in bug 67127 ?
This patch, adapted from others' patches in bug 67127, adds wrapping to
tooltips created using the TITLE attribute.  This particular patch uses CRs and
NLs if present in the attribute.
This patch, adapted from others' patches in bug 67127, adds wrapping to tooltips
created using the TITLE attribute.  This particular patch does not use CRs or
NLs found in the attribute.

These patches were tested with Firefox 0.8.  They wrap tooltips at 50 characters
rather than the original 64 to handle a string of W's.

I am fully aware that these patches are not perfect -- we should probably wrap
based on pixels or let another part of the Mozilla system like -moz-pre-wrap
handle wrapping -- but I'd really like to get long tooltips working sooner
rather than later.  I don't care which patch is used as long as something is
done to fix long tooltips.  :)
Whoops -- forgot the attachment.
Brad Town, you rock. 

May I also please give you a possibly redundant reminder that you may want to
flag your patch for review and superreview?
Flags: blocking1.7?
See bug 67127 comment 153 for discussion about -moz-pre-wrap and the bug that
stops that working is bug 228673 (as far as I can see)
Attachment #144860 - Flags: superreview?
Attachment #144860 - Flags: review?
Attachment #144863 - Flags: superreview?
Attachment #144863 - Flags: review?
Flags: blocking1.8a?
*** Bug 240482 has been marked as a duplicate of this bug. ***
not going to block releases on this bug.
Flags: blocking1.8a?
Flags: blocking1.8a-
Flags: blocking1.7?
Flags: blocking1.7-
*** Bug 242605 has been marked as a duplicate of this bug. ***
Any update on the reviews here?
Could it be that review(er)s are waiting for bug 228673 to be resolved, since
its set to block this. If that's the case, I've added a comment to that bug,
since its had no activity for 5 months, and isnt 100% relevant to this bug, afaics.
How much long (number of characters and number of lines) should be a tooltip
before being cropped? As far as I can say, this question was never
asked/discussed and never answered in this bugfile.
For how long a tooltip should be shown? Right now, tooltip show up for ~ 6 sec.
in Mozilla. I see a direct relationship between length+size and duration here.

Allowing title to be long for some elements would defeat/step over the purpose
of some other attributes (like the longdesc attribute). The HTML 4.01 spec and
WAI clearly mention "short message", "short description", "advisory title",
"informative link title"(1) for the title attribute. I'm not convinced that a
200+ characters tooltip meets the original goals of the HTML 4.01 spec. nor is a
good webpage design decision.

----
(1) "clarify the target of a link"
http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-meaningful-links
http://www.useit.com/alertbox/991003.html (see point 8)
http://www.w3.org/WAI/wcag-curric/sam77-0.htm
(In reply to comment #135)
> How much long (number of characters and number of lines) should be a tooltip
> before being cropped? 

I've always thought it should be an option: 
------
Tooltips: (*)crop or ()scroll at: [ 200 ] characters?  (default)
           or ()show full content
------

So someone could choose to crop them, or scroll them at whatever number of
characters seemed right to them, or always show full content of the title attribute.

But I'm not a programmer, so I wouldn't be able to do anything like this and 
have no idea how complicated it would be.  

-James
Re: Comment #135:  Unless the HTML specification sets a limit, Mozilla should
not assume any limit.  The tooltip should be wrapped, not cropped.  

If a tooltip is currently visible for 6 seconds, long tooltips should be visible
for (5 + n/5) seconds, where n is the number of characters.  That is, a
50-character tooltip would be visible for 15 seconds.  

Note:  I chose a divisor of 5 because a rule of thumb is that text of n
characters often contains n/5 words.  The formula then allows one second per
word plus five seconds to notice the tooltip and start reading.  Thus, the two
5s are not related.  Different constants might be used, but the concept -- a
latency for recognition and start-up (human, not machine) plus a linear function
of the size of the tooltip -- is appropriate.  If the divisor is smaller, that
gives slightly more time per word.  
(In reply to comment #137)
I'm sorry, but who takes that long to read a tooltip?  6 seconds is more than
enough time for me to read almost any tooltip - even if it has more than 5 words.

http://bugzilla.mozilla.org/attachment.cgi?id=137527&action=view

I would say that the third line tooltip in this attachment, which is 76
characters, should not be displayed for 5 + 15.2 = 20 seconds.  I can easily
notice and read it within 6 seconds... and having it up for 20 seconds would be
more annoying than not having multiline tooltips!

As for the length of title attributes... sometimes a longer one is needed to
properly describe things.  Yes, the spec does say short... but what is short?

You say short is less than, about, 200 characers.  I say short is... anything
less than a full paragraph of text.  We could aruge about this, but the truth of
the matter probably is that neither of us is right _or_ wrong.  HTML is, as we
both know, used for many things... and for different things the meaning of short
may be - well, different.

-[Unknown]
> I can easily notice and read it within 6 seconds...
> and having it up for 20 seconds would be more
> annoying than not having multiline tooltips!

Well, if you've already read it, just move the mouse cursor out of the hotspot..
. :)
Excuse me, but why does it have to be limited by time?
When I move my mouse cursor over a thread title to read it's content in the
tooltip, I don't want to be limited in time.
Asa, could you please explain why this bug cannot be blocking?
Flags: blocking-aviary1.0?
Attachment #144863 - Flags: superreview?(jag)
Attachment #144863 - Flags: superreview?
Attachment #144863 - Flags: review?(neil.parkwaycc.co.uk)
Attachment #144863 - Flags: review?
Comment on attachment 144860 [details] [diff] [review]
Tooltip wrapping patch (uses CRs and NLs if present)

I'm not sure which should be included.	Neil and Jag can figure that out.
Attachment #144860 - Flags: superreview?(jag)
Attachment #144860 - Flags: superreview?
Attachment #144860 - Flags: review?(neil.parkwaycc.co.uk)
Attachment #144860 - Flags: review?
Whould it be possible to accomplish this through userChrome.css?
http://www.mozilla.org/unix/customizing.html gives an example of recoloring
tooltips. What else can be done?
Flags: blocking-aviary1.0? → blocking-aviary1.0+
*** Bug 253899 has been marked as a duplicate of this bug. ***
Flags: blocking1.8a1-
Flags: blocking1.7-
Flags: blocking1.5-
Not a "blocker"
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
This bug is 4 years old and it has been put off once again. Fortunately someone
has created an extension that mostly fixes it.

http://white.sakura.ne.jp/~piro/xul/_popupalt.html.en

The pop alt extenstion has an option to "wrap long tool tips". Sorry all the
"don't you dare show me and alt text as a tool tip" folks. It also pops the alt
text in the abscence of a title tag too, darn!
(In reply to comment #146)
> This bug is 4 years old and it has been put off once again. Fortunately someone
> has created an extension that mostly fixes it.
> 
> http://white.sakura.ne.jp/~piro/xul/_popupalt.html.en

I noticed that uses window.setTimeout, so it got me thinking.  I think I may
have found a workaround for bug #228673.  It's by far not pretty, and I know I'm
doing it wrong.  But, here's what I've got, in the same place of browser.js that
attachment #137769 [details] [diff] [review] modifies:

...

  for (var i = 0; i < texts.length; ++i) {
    var t = texts[i];
    if (t && t.search(/\S/) >= 0) {
      tipNode.setAttribute("label", t);
      retVal = true;
    }
  }

  // If we found a title, set the box's height (but later after we're done.)
  if (retVal)
    window.setTimeout(function (node) {node.setAttribute("height",
node.boxObject.height);}, 0, tipNode);
  tipNode.setAttribute("height", "19");

...

The idea is, start everytime at 19, and then give the boxObject a chance to
draw; after that, resize it.  The time it takes to do this is noticable, but at
least it does work.  This is with slightly modified binding code (I was trying
it with a description) but the same from that patch should work.

I'd attach a patch, except I know this isn't going to cut it.  For one, 19 is
hardcoded there and would make large fonts (etc.) not work properly.  I don't
know how to get this properly, because my first choice, 1em, resulted in a 1
pixel tall popup for all single-line tooltips ^_^.

Perhaps this will give someone an idea?  If not, maybe someone can point me in
the right direction?

Thanks,
-[Unknown]
(In reply to comment #146)
> This bug is 4 years old and it has been put off once again. Fortunately someone
> has created an extension that mostly fixes it.

I have a feeling it is 1/2 a second away from WONTFIX. It was taken off all
possible blocking and put into "the future". 
This is still a problem:
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.3) Gecko/20040910

I count 27 other bug reports resolved as duplicates of this one, three such this
year.  This bug now has 145 votes, 93 more than at the end of April of last year.  

I don't think there can be any dispute that something does not work correctly. 
Resolving this bug as "WontFix" requires justification beyond the difficulty of
a fix, the lack of priority over other bugs, or the fact that this bug was first
noted more than four years ago.  
Repeatedly pointing out that this isn't fixed isn't going to get it fixed any
faster.  Workarounds and partial fixes have been posted here; if this bug
bothers you that much, incorporate those into your own setup.  I'm quite happy
with a modified popup.xml on my own system that incorporates attachment #144860 [details] [diff] [review].

My understanding is that this bug is blocked by bug 228673, as was mentioned in
comment #147.  Perhaps evangelistic efforts, if not bug-solving ones, would be
better directed there than here.
Re comment #150:  

My comment #149 was not intended to address the delay in fixing this bug. 
Instead, I tried to address the possibility that this bug might be Resolved as
WontFix.  

Patches and workarounds generally are well beyond the ken of unsophisticated
end-users who merely want a better browser.  I hope those users are a primary
target of the Mozilla Foundation because, without them, IE wins while Mozilla
and FireFox are relegated to interesting artifacts for software professionals. 
With a customer base of unsophisticated end-users, Mozilla can thrive and grow;
but that requires some attention to such minor but annoying bugs -- actual bugs
-- as this one.  Sweeping this bug (and others like it) under the rug by
declaring it WontFix could damage that needed customer base.  
Well, to be exact, this bug is:

4 Years, 79 days, 13 hours, and 32 minutes, or 1539 days, 13 hours, 32 minutes
old.  And in all this time, it's still losing data provided by the HTML
developer using the W3C standard TITLE attribute.  How can this be considered
W3C Standards compliant I don't know.  Pardon the cynicism, but, I think I've
earned it.

(BTW: This was written using Firefox 1.0PR1)
(In reply to comment #151)
> Instead, I tried to address the possibility that this bug might be Resolved as
> WontFix.  
I don't think any developers think this bug should be WONTFIXed.  The only
person who mentioned WONTFIX is "Sasquatch Bigfoot", who as far as I can tell,
hasn't contributed a single patch and owns no bugs.

The problem, as I understand it, is that the bug blocking this one depends on a
person who is no longer working on Mozilla doing some work, or another person
doing a huge amount of work.  If anyone would like to fix it, many people would
appreciate it.

Spamming a bug with comments like "why isn't this fixed?", "this bug still
annoys me", "don't wontfix this bug" and "this bug is really old and annoying,
you guys suck and don't care" doesn't help fix the blocking bug or this one - I
can't speak for other developers, but getting many useless emails about a bug
only makes me more likely to remove myself from the CC list and forget about it.
 Having to read through 150+ comments to find relevant information doesn't help
anything either.
This patch makes a few changes to Brad Town's patch #144863. It adds the string
"Title: ", wraps at 80 characters, and indents any wrapped lines by three
spaces.

This is my very first posting of a patch (and my first hack of Firefox), so try
to be gentle if I've done something wrong. I'm just trying to share.
(In reply to comment #154)
> Created an attachment (id=161763)
> Tooltip wrapping patch (uses CRs and NLs if present) with indents
> 
> This patch makes a few changes to Brad Town's patch #144863. It adds the string
> "Title: ", wraps at 80 characters, and indents any wrapped lines by three
> spaces.
> 
> This is my very first posting of a patch (and my first hack of Firefox), so try
> to be gentle if I've done something wrong. I'm just trying to share.


I'm pretty sure you have to ask for approval for this to get any traction. Not
sure how that's done, but thanks for the effort!
*** Bug 267259 has been marked as a duplicate of this bug. ***
*** Bug 269951 has been marked as a duplicate of this bug. ***
More related/duplicate bugs:

Bug 67127
Bug 104379
Bug 128998
Bug 218223
Bug 233371
Product: Core → Mozilla Application Suite
*** Bug 273768 has been marked as a duplicate of this bug. ***
*** Bug 275480 has been marked as a duplicate of this bug. ***
*** Bug 218223 has been marked as a duplicate of this bug. ***
I'm thinking of starting a traking bug for for all small anoying bugs that
really should be fixed my now. This would be straight on the list. 

Teach Me XUL I'll fix it ;p
Blocks: 164421
- I think that a bug that annoys so many people and has so many votes, deserves
Severity >= normal.

- Also, since the corresponding Firefox bug (bug 218223) was duped against this
one, shouldn't this one be "Product: Core"
Severity: minor → normal
Yeah, my baby is now 1659 days (about 4.5 years) old now.  And I'm preparing 
for her 5th birthday this year.  :)
*** Bug 280167 has been marked as a duplicate of this bug. ***
(In reply to comment #162)
> I'm thinking of starting a traking bug for for all small anoying bugs that
> really should be fixed my now. This would be straight on the list. 
...

(In reply to comment #163)
> - I think that a bug that annoys so many people and has so many votes, deserves
> Severity >= normal. ...


Here you go (this one is already listed):
https://bugzilla.mozilla.org/show_bug.cgi?id=163993
*** Bug 280251 has been marked as a duplicate of this bug. ***
(In reply to comment #164)
> Yeah, my baby is now 1659 days (about 4.5 years) old now.  And I'm preparing 
> for her 5th birthday this year.  :)

Crikey.. easily long enough to learn how to program and fix it yourself! :P
Flags: blocking-aviary1.1?
WTF!
You've had a patch for months which works fine, so why the hell wasn't it in
Firefox 1.0 and 1.0.1!

I think it would be a good idea if someone made a cross-platform xpi to apply
the patch and added it as an attachment for this bug discussion, to help less
technical people and sysadmins.

Luckily I'm a developer, so finally figured out where/how to manually apply the
fix.  I'm grateful that someone add patch attachnents, but IMHO there should
also have been a clearly titled attachment explaining how/where to apply the patchs.

(In reply to comment #169)
> WTF!
> You've had a patch for months which works fine, so why the hell wasn't it in
> Firefox 1.0 and 1.0.1!
I'm pretty sure there is or was something wrong with all of the patches.  Read
bug 228673 and make sure that *with* the patch, everything works properly.  Also
look at bug 67127 and make sure the testcases there work correctly.  If every
example works properly, let us know which patch you applied, and hopefully
someone will take another look at it.

> I think it would be a good idea if someone made a cross-platform xpi to apply
> the patch and added it as an attachment for this bug discussion, to help less
> technical people and sysadmins.
If it actually works properly, it can be incorporated into the next release.
> fix.  I'm grateful that someone add patch attachnents, but IMHO there should
> also have been a clearly titled attachment explaining how/where to apply the
patchs.
> 
> 

How does one apply the patch (which one btw- I see 3 patches- and voting for
using CR/Lf)- in my case in a Win2000 environment w FF 1.0.1?
There already is an XPI that fixes this. I guess it's not widely used because it
also displays the alt text if a title is not present. (The Horror)

This extension works perfectly with the testcase.

http://piro.sakura.ne.jp/xul/_popupalt.html.en
(In reply to comment #172)
> There already is an XPI that fixes this. I guess it's not widely used because it
> also displays the alt text if a title is not present. (The Horror)
> 
> This extension works perfectly with the testcase.
> 
> http://piro.sakura.ne.jp/xul/_popupalt.html.en

Please see comment #147.  Although, it looks as if it's been updated since I
last looked at it, and it looks a lot cleaner now imho.  I could attach a patch
based on its code, assuming I could obtain sufficient permissions from the
extension author to do so (as much as it does seem to be trilicensed.)

-[Unknown]
Regarding comment #173, the author of the Popup ALT Attributes
(http://piro.sakura.ne.jp/xul/_popupalt.html.en) said that his code could be
used as a starting point to fix this bug, as well as bug 228673 (though he
wasn't aware of these two bugs on bugzilla). He emailed me an explanation of his
code, but  stated that he thought the operations in his code seemed cosmetic
and, as such, a patch based on his code would probably get rejected.
Nevertheless, I am hopeful someone can take this code and work a patch out. I
will attach the relevent part of his email explaining his code...
*** Bug 295031 has been marked as a duplicate of this bug. ***
No longer blocks: majorbugs
*** Bug 247815 has been marked as a duplicate of this bug. ***
*** Bug 297414 has been marked as a duplicate of this bug. ***
is this is going to make the 1.8 branch?  should it?  it needs to have reviewed
and approved patches landed by 7/25 at 11:59pm p.d.t.

/cb
This bug is blocked by bug 228673. That bug needs to be fixed first, before any
of these patches can be used.
The lines in question that cause bug 228673, are found. Now, someone is needed
with enough C/XUL layout knowledge that can fix up that spot. 
Whiteboard: [seamonkey. blocked by bug 228673.]
"Link titles should be less than 80 characters, and should only rarely go above
60 characters. Shorter link titles are better."
J. Nielsen, http://www.useit.com/alertbox/980111.html

Whether Seamonkey and/or Firefox wrap text in tooltip or not is secondary to the
question of how long such tooltip are rendered. Right now, it's ~6 sec. If you
believe that a majority of readers can read over 128 characters in 6 sec., then
you're wrong, very wrong. Remember that tooltip (text size and box) are not
redimensioned when one increase the text size of a page: so that too affects
people ability to read tooltip. By default, tooltip use Tahoma 10px font-size on
Windows: we're not exactly speaking of normal text-size here or ideal text-size
for people over 40 years old - a very important and growing minority of web users.

Some people have answered that 6 sec. is more than enough to read a tooltip
without apparently considering length of such tooltip. For starters, the title
attribute in attachment 90744 [details] had 542 characters. I guess some would like
Mozilla to fix this bug and allow any number of characters in tooltip. That does
not make sense.

There is contradiction: would you like to see a 3inches by 3inches tooltip
covering the page during 30 seconds.. so that you would have all the necessary
time to read a long tooltip? Readers and users don't read like that. Readers and
users don't obey webpage design on demand like that: it's the entire opposite. A
3in by 3in tooltip displayed during 30 sec. would be exactly the same design
principle as unrequested popups.

Others have provided an algorithm for time duration of tooltip in respect with
length of title attribute but this kind of back-end code is exactly the kind of
code that would hurt performance. As a mouse hovers over links, and various
title-able elements, the application would have to calculate and store "x"
different values for "x" internal timers related to "x" different elements with
title attribute and then execute an internal timer when the mouse is over an
title-able element. This is definately not realistic.

What about W3C and WAI spec, recommendations on title? It seems that very few
people in this bugfile have paid attention on these. 

In my mind, if one needs to render more than 128 characters in a tooltip, then
one should ask himself how important such one hundred+28 of characters should be
to the user. And if it is important, then using, relying on a tooltip is not a
good idea, is not a sound webpage design decision. 

In my opinion, if a text, whatever it's purpose, is to be rendered to the user
in/during more than 6 sec., then it shouldn't be in a tooltip: basic common
sense suggests this. And if it can be read in 6 sec. and if it is not of
primordial importance, then it should not be more than 128 characters long to
begin with.

Supporting/promoting wrappable tooltip without any kind of sound limitations (on
length, on number of characters), without any kind of sane constraints is
promoting bad web design which will hurt users in the final instance.
One example among hundreds. I loaded attachment 125683 [details] which is mentioned in
comment 84. The title attribute had 175 non-space characters. If you load it in
MSIE 6, you won't be able to read that in 6 sec. You'll need to mouse over and
out and over again several times. And that page is not even a real live
representative webpage where there is usually a lot of stuff in a normal page.
Reference comment #181:

While the HTML 4.01 Specification and the WAI-WCAG indicate titles should be
short, "short" itself appears undefined.  It is possible that a title of only 60
characters may lack sufficient content (especially for audio browsers for the
visually handicapped).  Lacking an absolute criterion, the browser should handle
whatever size of title attribute value the Web author provides.  

I contend that calculating the persistence time of a tooltip at the time it is
needed (not calculated and stored as the page is loaded) would not create an
appreciable burden on browser performance.  The tooltip could appear immediately
and the timer started while the persistence time is calculated.  Generally
(except with very old computers), the calculated time will be available even for
short titles before the tooltip has been displayed too long.  I would even add a
user option for the tooltip persistence as "normal", "long", or "short",
adjusting the formula accordingly.  

(In reply to comment #183)
I would even add a
> user option for the tooltip persistence as "normal", "long", or "short",
> adjusting the formula accordingly.  

Users don't want to choose how long tooltips are displayed for.

Is there any good reason not to continue showing tooltips indefinitely?
(In reply to comment #184)
> Is there any good reason not to continue showing tooltips indefinitely?

Tooltips are not shown indefinitely, they appear exactly for 6 seconds. I'd
suggest discussing the request for a longer/adaptive timeout in a separate bug
(if none exists, file one), as it is clearly a separate issue.

Besides, with or without a timeout, the request to wrap tooltips instead of
cropping them is valid.
> While the HTML 4.01 Specification and the WAI-WCAG indicate titles should be
> short, "short" itself appears undefined.  It is possible that a title of only 60
> characters may lack sufficient content (especially for audio browsers for the
> visually handicapped).  Lacking an absolute criterion, the browser should handle
> whatever size of title attribute value the Web author provides.

Everywhere in HTML 4.01 and WAI specs, it is clearly indicated what is the
purpose of the title attribute. If quantitative length is not defined, then the
normal next step to do is to evaluate and assess how many characters a wide
majority of users can read in 6 seconds - *that is what browsers have set in
MSIE 5+ and Mozilla* - , in a non-scalable size, in a fugitive/intermitten
manner and you should not be far away from 60-80 characters. It is *not* any
size: it is 6 sec. and its relation to how much a wide majority of users can
read in 6 sec.
"Short", length, number of characters must be intimately related (or
proportional, if you want) to that 6 sec. duration because this is how current
browsers handle title attribute.

Tooltip text is much more constraining, limitative than one could think: 
- the user can not copy and paste the text appearing in a tooltip, 
- the user can not resize the text-size on the fly, 
- the user can not see the title attribute value if he's using keyboard
navigation in any/all browsers I tested this: no tooltip, nothing, 
- the user can not resize tooltip box, 
- the user can not resize the text-size unless he knows where in the os, 
- the user can not modify the time/duration of appearance of the tooltip
etc..
and for all these reasons, web developers should not put anything primordial in
it, web developers should not put long (over 128 characters IMO) content in it,
web developers should not put anything besides complementary info, advisory info
in it, just like HTML 4 and WAI are explicitly saying. 

All I read in this bugfile is the demand for wrapping of its text
*independently* of all the other issues related to it and despite webpage design
issues. There is such a thing as hardward limitation. There is such a thing as
software limitation. And there is such a thing as users limitation: people do
not read in 6 sec. whatever you throw to them. That still will remain true
whether browsers wrap or do not the tooltiped text.

The simplified testcase of attachment 90744 [details] had 138 words, 542 non-space
characters and 688 characters: and you want/expect users to read all of it in 6
sec.?
Again, people do not obey webpage design on demand like that; people do not read
whatever you throw at them.
> I contend that calculating the persistence time of a tooltip at the time it is
> needed (not calculated and stored as the page is loaded) would not create an
> appreciable burden on browser performance.

By itself, alone, in the absolute, calculating time duration, storing related
values, pointers in memory, etc.. does not require a lot of system resources for
the browser application but consider that there might be many title-able
elements in a single page, there might be several pages loaded in several tabs
and consider what a typical browser has to do to parse, render, draw in a page
and you'll end up with a clean and clear increase of burden for the application.
All of this has to be calculated, stored and then timed with specific. Finely
tuned and time-dependent setting always affect performance. The module owner
will not ignore this issue when the fate of this bugfile will be decided.
(In reply to comment #186)
> If quantitative length is not defined, then the
> normal next step to do is to evaluate and assess how many characters a wide
> majority of users can read in 6 seconds - *that is what browsers have set in
> MSIE 5+ and Mozilla* - , in a non-scalable size, in a fugitive/intermitten
> manner and you should not be far away from 60-80 characters. It is *not* any
> size: it is 6 sec.

You're contradicting yourself. Internet Explorer also shows tooltips for only 6
seconds, but it *does* wrap the text. So it seems there is no reason to connect
timeout and text length, right? And even there was such a reason, what makes you
believe that we cannot or should not change that six second timeout? After all,
the six seconds are not part of any specification.

Apart from that: If you want to discuss this further, please *refrain* from
adding further comments to this bug - it is already long enough, and bugzilla is
generally not meant for this type of discussion. Instead, I advise you to create
a thread on http://forums.mozillazine.org (e.g. in the 'development' section).
You people are only considering "web developers", "web masters", "web
designers", when you're forgetting people whose simple role is "content
developers", people who use tooltips as foot notes and, as such, they should
have any size.

Provided that bug #45375 is solved (the present bug), tooltips are effectively
the most comfortable way of providing footnote functionality on computer screen
media.
The best test case is right on this page.

I think the folks that code BugZilla are competent web developers. And, right
here on this page there are tips that FX and Moz can't properly display. Hover
the mouse over the links to the blocking and Depending bugs at the top of this page.

The title of the bug is supposed to be displayed, saving a click to see that
it's about. The tip for 228673 and 251123 are not properly displayed, they're
chopped off.

Even the best web developers need tool tips that can display more than 80
characters. This case proves that.

P.S. And yes, I have to re-hover it to read the whole thing but I'm so used to
that I can do it without losing my place. Six seconds or whatever the norm is is
fine.
> You're contradicting yourself. Internet Explorer also shows tooltips for only 6
> seconds, but it *does* wrap the text.

Where have I said that IE's design was logical, coherent, recommendable, that we
should follow IE's design? It does wrap the text: bravo for them. It allows any
amount of characters into a tooltip: that's illogical, incoherent, bad design,
etc.. That's my position.

The same should be said about the status bar. In your own logic, the status bar
should expand, should stretch when the window.status message exceed the
available number of characters for the message area, so that it would be
displayed entirely and not be cropped like it is now in IE, Mozilla, Opera. IE,
Mozilla, etc.. browsers should not crop text in the status bar: it should wrap.

 So it seems there is no reason to connect
> timeout and text length, right?

Don't ask me. I already answered that. Instead, ask ordinary users that question
and get to know what ordinary people are saying, how they feel about a tooltip
of 150, 200, 250 characters displayed in Tahoma 8px (that's the default
text-size for normal text btw on windows) for 6 sec. If you think that these 2
(timeout and text length) should not have any kind of relationship, then a lot
of people will/should agree with you on this.


> And even there was such a reason, what makes you
> believe that we cannot or should not change that six second timeout?


I am for consequent design and coherent thinking, UI planning. If you decide on
a 6 sec. timeout delay for the appearance of tooltip, then the text lenght,
number of characters allowed in there should be reasonably related with such
delay. If you decide on a 29 sec. timeout delay for the appearance of tooltip,
then  the text lenght, number of characters allowed in there should be
reasonably related with such delay. I thought my previous comments were clear on
that issue. Read again my comments where I use the words related, relation,
proportional and similar words.

 After all,
> the six seconds are not part of any specification.
> 

That six seconds is a Mozilla browser behavior. That six seconds is a MSIE
behavior. I did not create that behavior nor am I suggesting you did either. If
you believe there is a problem with that 6 sec., then you should file a bug
accordingly to change that. Otherwise, web developers should deal consequently
with such constraint. And users, webpage visitors should cope with, live with
the web developers design.
Its really anoying when the cro...
Its really anoying when the cro...
> The tip for 228673 and 251123 are not properly displayed, they're
chopped off.

Charles, I don't know what you mean. Over here,

228673
NEW - boxObject.height is not being calculated correctly for xul:label with
certain styles  
90 characters
is displayed entirely in a tooltip (no chop, no crop) with Mozilla Seamonkey
build 2005080706 with default normal font size in XP and with Font size: Large
Fonts size in XP. (Start/Settings/Control Panel/Display/Appareance tab/Font size:)

251123
NEW - HTTPS lock icon does not explain mixed secure/non-encrypted icon when
hovering   
84 characters
is also displayed entirely in a tooltip (no chop, no crop) with today's build
with normal font size and with large font size in XP.

I can send 2 screenshots if we need to go this far.
Gérard, you've missed the point. OK, tonight's nightly renders title text a
couple of characters longer. That is not the point of this bug. The following
titles dispersed through this page and on bug 164421 do not render correctly, or
should I say as the designer intended. The intent was to save you clicking on
the bug to see what it was about. Because Moz chops off the text you have to
click the link the see the complete title of the bug. 

bug 144484
bug 56314
bug 171349
bug 232895
bug 78692
bug 106382
bug 116142
bug 153168
bug 117597

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050806
Firefox/1.0+

W3C does not specify any limit to the length of the text or how it's rendered.
There is no "standard", it's up to the browser designers how it should be
rendered. The recommendations on Jakob Nielsen's page are just that,
recommendations. Not a standard. Every other browser manufacturer has decided to
display the title attribute as the page author intended it. Other than "not
because everybody else does it" it there a good reason to alter the authors
original intent? If you don't like long tips, fine. Don't read all of it and
point the mouse somewhere else. Most users don't give a hoot about "standards"
or "recommendations" they just want to see the page the way the author intended it.
There are two issues here:

1. How much of the Title attribute text is to be displayed.

The only logical and useful answer is "all of it". To display less would be
almost useful. The author decides what should be displayed, not the User Agent!
(The user has a say in this, too. The UA could provide options re handling of
title attribute text for selection by the user: Ignore/Display/Speak, etc.)

2. How long should Title attribute text be displayed.

Again, the answer seems obvious: "Display as long as the user wants to see it."
Or hear it, or whatever. The key is that it is the user who should decide, not
the user agent. The user usually signals his intent by hovering the mouse cursor
over the element. Display (or speak, etc.) the title text as long as the user
continues this signal.

-R.
What you really want is a system like Eclipse has, where you get a reasonably
sized tooltip when hovering, and if the text is larger than that it puts
"...press F2 to focus" at the bottom of the text, and when you hit F2, you get
scroll bars which give you access to the whole text until you hit ESC or click
somewhere else to remove the window.
(In reply to comment #181)
> "Link titles should be less than 80 characters, and should only rarely go above
> 60 characters. Shorter link titles are better."
> J. Nielsen, http://www.useit.com/alertbox/980111.html

Please, tell me you aren't confusing a "usability guru"'s recommendation with a
standard...

> Some people have answered that 6 sec. is more than enough to read a tooltip
> without apparently considering length of such tooltip. For starters, the title
> attribute in attachment 90744 [details] [edit] had 542 characters. I guess some would like
> Mozilla to fix this bug and allow any number of characters in tooltip. That does
> not make sense.

Yes, it does.  It is not for Mozilla to dictate to Web developers how long their
tooltips can or should be, as long as other browsers handle those same tooltips
without any problems.  That kind of attitude will only give them one more reason
to develop exclusively for IE, at which point all the standards in the world
won't help Mozilla.

> There is contradiction: would you like to see a 3inches by 3inches tooltip
> covering the page during 30 seconds.. so that you would have all the necessary
> time to read a long tooltip? Readers and users don't read like that. Readers and
> users don't obey webpage design on demand like that: it's the entire opposite. A
> 3in by 3in tooltip displayed during 30 sec. would be exactly the same design
> principle as unrequested popups.

IE manages to handle the ultra-long tooltip in the first attached test case. 
Why not take that behaviour as the base, implement it, then improve on it later?
 It would satisfy many of the people who have been waiting here for a solution.

> What about W3C and WAI spec, recommendations on title? It seems that very few
> people in this bugfile have paid attention on these. 

Those specs do not mention any concrete length.  There is only the mention of
"short", which is completely subjective.

Also, you will find that "very few people have paid attention on these" is true
of the Web development & design community as a whole.

> In my mind, if one needs to render more than 128 characters in a tooltip, then
> one should ask himself how important such one hundred+28 of characters should be
> to the user. And if it is important, then using, relying on a tooltip is not a
> good idea, is not a sound webpage design decision. 

Firstly, most Web developers /do not/ take sound webpage design decisions. 
That's the reality.

Secondly, there are situations where the only option is to convey the
information via a tooltip, to further facilitate uninterrupted reading of an
article, yet at the same time provide information only tangentially related.

> In my opinion, if a text, whatever it's purpose, is to be rendered to the user
> in/during more than 6 sec., then it shouldn't be in a tooltip: basic common
> sense suggests this. And if it can be read in 6 sec. and if it is not of
> primordial importance, then it should not be more than 128 characters long to
> begin with.

See my second point above.

> Supporting/promoting wrappable tooltip without any kind of sound limitations (on
> length, on number of characters), without any kind of sane constraints is
> promoting bad web design which will hurt users in the final instance.

Agreed.  However, proposing a rather small length -- which will most certainly
be exceeded as soon as the developer realizes that IE renders it fine -- will
hurt Mozilla in the final instance.

On another note, I personally like tooltips to stick around till I remove my
cursor, but that seems to be rather contrary to popular opinion... ;-)

Aankhen
> On another note, I personally like tooltips to stick around till I remove my
> cursor, but that seems to be rather contrary to popular opinion... ;-)

I think that would be excellent, and probably most that have supported this bug. 
(In reply to comment #197)
> What you really want is a system like Eclipse has, where you get a reasonably
> sized tooltip when hovering, and if the text is larger than that it puts
> "...press F2 to focus" at the bottom of the text, and when you hit F2, you get
> scroll bars which give you access to the whole text until you hit ESC or click
> somewhere else to remove the window.

That would be acceptable -- as long as the user can see the _entire_ title in
some way. 

It is very frustrating to only be able to see _part_ of a tooltip. The author
has provided a message to the user. To see only the first "n" characters is
plenty maddening. Was the rest of that message important? Why can't I see it?
What will happen if I cannot act on the advice hidden from me? 

-R.
> Gérard, you've missed the point. 

This bugfile is about long tooltips being cropped and not wrapping at tooltip
box edge. That's what the summary says. Notice that no one ever quantified how
long is "long". How long is long enough? Some even suggested that user screen
limitation should not even get in the way of their title attribute.

OK, tonight's nightly renders title text a
> couple of characters longer. That is not the point of this bug. 

I merely replied to what you said in a resounding manner: "The best test case is
right on this page."

The following
> titles dispersed through this page and on bug 164421 do not render correctly, or
> should I say as the designer intended. The intent was to save you clicking on
> the bug to see what it was about. Because Moz chops off the text you have to
> click the link the see the complete title of the bug. 
> 
> bug 144484
> bug 56314
> bug 171349
> bug 232895
> bug 78692
> bug 106382
> bug 116142
> bug 153168
> bug 117597
> 

I can read the 90 (or so) first characters of each of these bugfiles' summary in
a tooltip and then have a good idea of what these bugs are about. And that fits
precisely and exactly what the W3C, WAI, WCAG and J. Nielsen say about link
title attribute purpose. Just mouse over these bugfiles links yourself like I
did, the way I did, having in mind the purpose of the title attribute as clearly
defined by the spec: "value of the 'title' attribute that clearly and accurately
describes the target of the link" WCAG 1.0 section 6.1
In many of these links, only a few characters are clipped.

Try this one:

bug 281565

Where is the real problem, issue exactly according to you? In the tooltip
handling by Mozilla browsers or in the edition of the summary?


> Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050806
> Firefox/1.0+
 
Is this bugfile applying to Firefox too? Just asking.

> W3C does not specify any limit to the length of the text or how it's rendered.

W3C/WAI/WCAG say "short message", "short description", "advisory title",
"informative link title". Nowhere do I read that title should be long message,
that long is ok or recommendable, that long title would have to render in long
tooltip.
All the examples given in technical documents of W3C/WAI/WCAG use under 60
characters in title. Nowhere do you see something supporting more than 100 or
128 characters. It's the opposite.

All technical documents at W3C I read so far promote the usage of title for
<abbr>, <acronym>, <a>, <link>, client-side image map, <frame> with <a> being
the most frequent, important. In this bugfile though, we see demand to support
unlimited length of title attribute for <p>, for <div> and any other element.

Technical documents I read last night at W3C explicitly discourage use of title
attribute for <table>, <caption> and <img>.
They also explicitly insist on having the link text describe, indicate the
nature of the link target.

There is also another issue that no one mentioned so far: you can read very long
title in the link properties non-modal window. You can even copy and paste it if
you want. No need to view the source view. Unless I'm wrong, that is part of
UAAG 1.0 guidelines under conditional content sections.


> There is no "standard", it's up to the browser designers how it should be
> rendered. 

What about the users then? How much text in Tahoma 8px can *you* read in 6 sec.?
I'm asking you an honest and fair question here. 
6 sec. and Tahoma 8px are default on the most frequently used os on the web.

What about organization of info in a webpage then? Is it ok to display a 3inches
by 5 inches tooltip to render 1000 characters when hovering over a 2 word link
text? Where do you exactly draw the line in this issue? If there is no
standards, then what would basic common sense suggests for a 6 sec. tooltip? If
anything is good (no limit, no standard) for the tooltip, then the next logical
step would be to demand more flexibility (resizability, colors, font, etc.),
usability (text scalable), interoperability (eg copy and paste) for tooltip. And
then also demand that titlebar expands, stretches to wrap line and not crop long
title elements. And also demand that status bar expands, stretches vertically to
render all of the author's original message in the window.status string. And
demand more authors intents in/over any/all UI components (contextmenu, control
over toolbar presence, etc.). There is no end to what an author would request
from browsers.

> The recommendations on Jakob Nielsen's page are just that,
> recommendations. Not a standard. 

I personally would not reduced his recommendations to mere opinions. The guy is
world-widely respected for the impressive empirical studies done with user
groups, with tests in user groups. He does not just wake up one morning saying
to himself "Yeah, 60-80 is good enough for a title attribute. Yesterday I
stumbled across a page that had 500 characters in one of its link title. How
annoying! I'll write an article on that." The guy tests, researches, verifies
those issues. And he's certainly making sense on a lot of issues. 

> Every other browser manufacturer has decided to
> display the title attribute as the page author intended it.

They also try to follow UAAG 1.0 guidelines too, advices based usability
studies, etc.. They don't have an "anything goes" attitude anymore, they more
and more give more veto powers to users too: an overwhelming amount of design
decisions and implementations (unrequested script-initiated windows, status bar,
marquee, flashblock, etc.) substantiate my claim here. Authors original intent
just do not have the last word anymore. Authors original intent is not a
sufficient justification by itself, authors original intent should not allow
everything just because it's authors original intent.


> If you don't like long tips, fine. Don't read all of it and
> point the mouse somewhere else. 


I think what you say here is very revealing.


Most users don't give a hoot about "standards"
> or "recommendations" they just want to see the page the way the author
intended it.
> 

People using popup blocking, flashblock, tabextensions, user stylesheets,
etc.etcetc... do not want to see pages the way some/many of their authors
intended. Sorry. "Like it or not" manners, "the sky is the limit" views and
"anything goes" policies just lead to chaos, abuse or to nowhere. 
"Take back the web" was and is addressed to the users, you know, not to the web
authors.
Could the keywords "compat" and "conversion" be added?

Also, I agree that tooltips should be displayed for as long as you hover over
the title'd element.  Mozilla should in no way determine the reading speed of a
user nor the importance of the title content.
Agreeing with Matt on comment 202.

Tooltips are not used only to title images and links, a very common use of
tooltips is for a "peak" in the link target (like threads on vBulletin).

There is no excuse to determine 6 seconds for reading a tooltip that has
multiple lines. And there is no excuse to limit a tooltip to just one line.

And just a side comment (I hope this isn't inappropriate here): I think this bug
is just an example of many other Bugzilla bugs, where the answer on what should
be done is pretty clear - yet some people insist on leaving things just the way
they are now.
It almost feels like many Mozilla developers are scared of changes.
One can argue this point on both sides, forever... but we shouldn't.

What can be agreed on, by most everyone (regardless if it goes against
recomondations, or whatever) is:


a.) Tooltips should be *able* to wrap
b.) Tooltips should show *whatever* was requested in the attribute, within
reasonable expectations. (e.g. If I put 256 chars in my tooltip, for my Web
Application, I would expect to see it... beyond this, one can argue if it is
reasonable or not***... but 256 isn't going to bring down the Web)
c.) Since many argue over the delay, moz could always make this an about:config
prop... "accessibility.tooltip.displayduration: int (-'ve = until unmousedover,
else +'ve = # of seconds)

*** (Please argue this AFTER 256+ w/line feeds is enabled)
> > Some people have answered that 6 sec. is more than enough to read a tooltip
> > without apparently considering length of such tooltip. For starters, the title
> > attribute in attachment 90744 [details] [edit] [edit] had 542 characters. I guess some
would like
> > Mozilla to fix this bug and allow any number of characters in tooltip. That does
> > not make sense.
> 
> Yes, it does.  It is not for Mozilla to dictate to Web developers how long their
> tooltips can or should be, as long as other browsers handle those same tooltips
> without any problems. 

Ok, so you're saying that Mozilla should implement what other browsers have
already implemented and then not bother about implementation issues (eg possible
annoyance to users) like length of title attribute of web authors: it's not
their business. That is what I understand from you. 
"Others do it, so it makes sense to do it too" is in itself a rather weak argument.

 That kind of attitude will only give them one more reason
> to develop exclusively for IE, at which point all the standards in the world
> won't help Mozilla.
> 

IE 7 will implement tab browsing, you know. Tab browsing was nowhere in any W3C
TRs/standards I know of. IE 6 SP2 prevents web authors from removing status bar,
also implemented popup blocking. Again, there was nothing in the W3C web
standards which addressed such precise issue either. 

Web browser development trend is not a pure white or black trend or a lineary
one and definately not an "either follow IE or die/disappear".


> > There is contradiction: would you like to see a 3inches by 3inches tooltip
> > covering the page during 30 seconds.. so that you would have all the necessary
> > time to read a long tooltip? Readers and users don't read like that. Readers and
> > users don't obey webpage design on demand like that: it's the entire opposite. A
> > 3in by 3in tooltip displayed during 30 sec. would be exactly the same design
> > principle as unrequested popups.
> 
> IE manages to handle the ultra-long tooltip in the first attached test case. 

Can you specify what's in your opinion a "short", "normal", "long" and then
"ultra-long" tooltip? Number of characters please.

> Why not take that behaviour as the base, implement it, then improve on it later?

Maybe because good planned design is not an adventure or improvisation; maybe
because it's better to better design than the competition and to focus first of
all on implementations that safely improve the users' experience. 
I'll ask you what I've asked Charles: how much text content can *you* read in 6
sec. with Tahoma 8px? 

How many times do you need to mouse over and out to read the testcase of
attachment 90744 [details] with MSIE 6? Do you like, enjoy reading content in rigid,
non-flexible, non-scalable tooltips like that? I'm not trying to trick you with
such questions: because this is actually and factually what happens to users
when meeting 200+ characters tooltip in MSIE and trying to read such tooltip.

>  It would satisfy many of the people who have been waiting here for a solution.
> 

Irrelevant. Leadership is about what's best/sound/promoting constructive future,
not about what's most popular. Mozilla - or module owner/reviewer - will not
implement a feature that he knows could/will harm, annoy, confuse - whatever
here - its users. If two thousands people had voted for this bug, I'd probably
vote against fixing it if I could because I feel the current way title attribute
is handled by Mozilla and Firefox is reasonable, balanced, level-headed, meets
known W3C documents/specs and promotes reasonable, rational webpage design.

> > What about W3C and WAI spec, recommendations on title? It seems that very few
> > people in this bugfile have paid attention on these. 
> 
> Those specs do not mention any concrete length. 

Long does not refer to any quantitative/concrete length in this bugfile either.
Personally, I'd say that too long is over, greater than the number of characters
that a wide majority of users can read in 6 sec. with Tahoma 8px.

> There is only the mention of
> "short", which is completely subjective.

They also use title attribute in the examples in their recommendations (WAI,
WCAG 1, 2, HTML 4, etc). So "short" is not *that* mysterious. And the purpose
served by the title attribute is clear and explicit in the official W3C specs
and several W3C documents.

> Firstly, most Web developers /do not/ take sound webpage design decisions. 
> That's the reality.

Well, that is what I think too.


> Secondly, there are situations where the only option is to convey the
> information via a tooltip, to further facilitate uninterrupted reading of an
> article, yet at the same time provide information only tangentially related.
> 

Well, go ahead and bring up a good testcase demonstrating that, showing
exemplarily what you mean/say. Because so far, I have not seen any good
realistic testcase in this bugfile to substantiate your claim. Hovering the
mouse over a red <div> that has no visible content at all and then I should be
reading 688 characters in 6 sec. intermittently is not what I would consider a
good realistic testcase promoting a change in handling 500+ characters long tooltip.

> > In my opinion, if a text, whatever it's purpose, is to be rendered to the user
> > in/during more than 6 sec., then it shouldn't be in a tooltip: basic common
> > sense suggests this. And if it can be read in 6 sec. and if it is not of
> > primordial importance, then it should not be more than 128 characters long to
> > begin with.
> 
> See my second point above.
> 

The "What other browsers do" argument should overcome common sense, reason,
wisdom and sound features? 

Hypothetically speaking:
- If MSIE 7 implements tooltip at 3 sec. delay with Tahoma 4px, should we follow
MSIE 7 then? 
- Let's say Seamonkey 1.0 implements tooltip with 6sec. delay, line-wrapping at
tooltip box edge for any number of characters, just like it is right now with
MSIE 6. Then what should Mozilla do if/when MSIE 7 final release implements
cropping tooltip at 90 characters? We would have to yo-yo back to where we were
only because "What other browsers do" is enough to dictate what Mozilla should do.

Mozilla implemented a lot of features (tab browsing, flash blocking, popup
blocking, etc) and a lot of W3C web standards (HTML 4, CSS, DOM, js, etc.) which
were not implemented in IE, Mozilla implemented a lot of features and standards
despite and regardless of IE's failure to implement these. The whole Mozilla
browser development history of the last 5 years does not support a passive
follow-IE policy and in fact goes against a blind follow-IE policy.

Mozilla implemented the scrollIntoView() method which was first introduced by
IE. Not only Mozilla did not implemented exactly like IE but Mozilla made it a
better, more useful method. The same could be said for a short list of
non-standard features, methods or properties which were already/first introduced
by IE.

> > Supporting/promoting wrappable tooltip without any kind of sound limitations (on
> > length, on number of characters), without any kind of sane constraints is
> > promoting bad web design which will hurt users in the final instance.
> 
> Agreed.  However, proposing a rather small length -- which will most certainly
> be exceeded as soon as the developer realizes that IE renders it fine -- will
> hurt Mozilla in the final instance.
> 

People (web authors) will have to adjust like they have for unrequested popups,
flash, marquee,  etc.

> On another note, I personally like tooltips to stick around till I remove my
> cursor, but that seems to be rather contrary to popular opinion... ;-)
> 
> Aankhen

It's 6 seconds in Tahoma 8px with MSIE 6. And you're saying we should follow
MSIE here.
***

Okay, I think both sides have explained their opinions in detail. No side will
convince the other, so it's really time to *stop* commenting now, and leave this
bug untouched until either a) someone starts implementing it or b) it is
WONTFIXed. Further comments (whether for or against fixing this) do *not* bring
*any* advantage for the Mozilla project as a whole or individuals. This bug is
already near uselessness, let's not make things worse.

***
PLEASE people, stop commenting on this bug here. You added 24 (mostly) pointless
comments in the last two days which were not of any use towards fixing this bug
here. There's no point adding any further comments, Bugzilla is not the place
for this, discuss anything further in the mozillazine.org forums or in the
netscape.public.mozilla.* newsgroups.
Attachment #144860 - Flags: superreview?(jag)
Attachment #144860 - Flags: review?(neil.parkwaycc.co.uk)
Attachment #144863 - Flags: superreview?(jag)
Attachment #144863 - Flags: review?(neil.parkwaycc.co.uk)
Blocks: 296937
Gérard Talbot was asking for an example where a long tooltip is useful.  Several online comics, like Achewood.com and Qwantz.com, encode punchlines in the title tag.  This seems both tangential and useful to me.  I don't understand why this bug is such an issue, but I think it's rapidly becoming an embarrassment for Moz, especially judging by all the comments here.

The arguments over the “illogic” of allowing infinitely-long tooltips are pretty pie-in-the-sky, too.  All most people want here is for the tooltip length to be extended to a reasonable amount.  I imagine if you starting chopping off text at 6,000 characters, instead of something like 60, people would no longer care that things are being truncated, because it’s usable.  As it stands, it’s ridiculous.
(In reply to comment #208)
> Gérard Talbot was asking for an example where a long tooltip is useful. 
> Several online comics, like Achewood.com and Qwantz.com, encode punchlines in
> the title tag.  This seems both tangential and useful to me.  I don't
> understand why this bug is such an issue, but I think it's rapidly becoming an
> embarrassment for Moz, especially judging by all the comments here.
> 
> The arguments over the “illogic” of allowing infinitely-long tooltips are
> pretty pie-in-the-sky, too.  All most people want here is for the tooltip
> length to be extended to a reasonable amount.  I imagine if you starting
> chopping off text at 6,000 characters, instead of something like 60, people
> would no longer care that things are being truncated, because it’s usable.  As
> it stands, it’s ridiculous.

Agreed completely, though they'll just say "it's Onstad's fault for ignoring standards, not ours!!1"

Note that there is a Greasemonkey script for displaying those tags below the image as text, which I use as a workaround for Achewood:

http://userscripts.org/scripts/show/559
Here is an easy fix for this bug that nobody has thought o
(In reply to comment #208)
> Gérard Talbot was asking for an example where a long tooltip is useful. 
> Several online comics, like Achewood.com and Qwantz.com, encode punchlines in
> the title tag.  This seems both tangential and useful to me.  I don't
> understand why this bug is such an issue, but I think it's rapidly becoming an
> embarrassment for Moz, especially judging by all the comments here.
> 
Here's an example:
I'm working on a project-based app for small to medium manufacturing that needs to report the status of the materials in the project.  A material's status might be project-specific and thus not affecting the same material within a different project or it may be inventory related (which would affect this material in all projects).  We use the mouse-hover tooltips to provide an explanation of the status indicator (which is a color-coded icon).  In the case where the project-specific status is different from the inventory status, we need to be able to display an explanation of both status values within the same tooltip popup.
(In reply to comment #211)
> Here's an example:
> where the project-specific status is different from the inventory status, we
> need to be able to display an explanation of both status values within the same
> tooltip popup.

This is the biggest reason this bug SHOULD be fixed yesterday, my understanding is that we are trying to get people to use the mozilla/firefox etc. browsers.
  
If you ignore a feature that is necessary for the use of a website, and in no way breaks the standard you are not going to get people to switch.  

An intranet site I maintain uses the title tag to display the address of a vendor, this is critical when you have a number of vendors with almost identical names, the user NEEDS to be able to determine which is the correct vendor.  One of the sites that this app is deployed at rejected firefox specifically because the way it screws up the title hints made their main app unuseable. 

Arbitrarily truncating the title hint was far worse than doing nothing at all, in the above example a lot of the time all the user cared about was what city the vendor was in, and city is at the end of the address so gets cut off.


I hate to do this, because this isn't what Mozilla (& Firefox) are all about, but it is unfortunately NECESSARY. Firefox 1.5 RC2 is on the horizon, and this simple bug, has not been fixed.

So, I hereby offer to send $25 by paypal, to the developer/manager that gets a fix for this checked in.  I don't care if it is limited to 4 lines, or 1024 characters, or whatever... but ANYTHING more than what is currently provided, would be welcome, and quite frankly, long overdue.

I realize that money-as-incentive is not the way this software should be developed, but this particular bug's lack of a solution is driving us nuts.  This bug has been open for 5 (FIVE!!!) years!!!

In addition, it scares me, that this bug apparently depends on bug 228673, which is currently assigned to nobody! (nobody@mozilla.org)

I hereby BEG someone to take a lead here, and get something done about this.

Thankyou.
PS Before anyone bites my head off for attempting to bribe, or anything else, please read the whole post.  I just want this fixed, and it boggles my mind, that the squabbling over the semantics of the issue, are blocking a fix from being applied.
(In reply to comment #213)
Steve, I assure you that this kind of post will do the exact opposite of helping to fix this bug.
In other words, you are not encouraging anything.
Steve, sponsoring OSS is a good thing. I sponsor myself other OSS projects when a project I'm working on requires it.

I hope someone picks up on your offer.
Ido, quite true, and I'm sorry for any adverse results.

I still feel that this issue, is not even being looked at, evidenced by the fact that the dependent bug, is unassigned.

As a side note, Bugzilla, could really use a feature, where each user, can not only vote for bugs, but vote for:

  (x) Vote this bug, as my #1 bug.

There are several bugs, in my/others lists... the consolidated voting results, appear to "determine" the most important, however, sometimes, fixing the end-user/developers #1 issue, is worth more than fixing 10 other bugs.

I understand that Mozilla still works without a fix for this, and that if it never got fixed, the world wouldn't end, but sometimes the "little things" are so important, it isn't funny.

E.g. A TV works just fine, without a remote.  However you would never make any money selling one, without the remote.

This bug is like this.  As Users/Developers/Evangelists of Mozilla Products, we want success in the market, to ensure a future position in the market, and the ability to compete, if not exceed our competitors.  However, little "glitches", like this one, are the kind of thing that will stop users from "accepting" Mozilla, and stop Web Application Developers, from fully embracing the power of Mozilla.

Thanks.

(In reply to comment #216)
> As a side note, Bugzilla, could really use a feature, where each user, can not
> only vote for bugs, but vote for:
> 
>   (x) Vote this bug, as my #1 bug.
> 
> There are several bugs, in my/others lists... the consolidated voting results,
> appear to "determine" the most important, however, sometimes, fixing the
> end-user/developers #1 issue, is worth more than fixing 10 other bugs.
Sounds like a perfectly valid idea.
If you want to make it happen you should probably make a Bugzilla enhancement request here: https://bugzilla.mozilla.org/enter_bug.cgi?product=Bugzilla
Is this a Seamonkey-only bug as it says in the status whiteboard and product fields, or would fixing this also fix Firefox? If the latter, please fix the status whiteboard and product fields, and reset the QA contact appropriately.

The way this should work is that if the text in the tooltip is too long, it should auto-wrap. In addition, any U+000A characters found in the attribute value should be treated as explicit line breaks. In attribute parsing, line breaks: "
" should be converted to spaces, and &#x0A; should be converted to literal U+000A characters in the title attribute value.
I can't believe it's been 5 years...I sure hope somebody comes up with a fix =/
Is there som sort of serious issue with getting this fixed? Is this not simple fix?

Maybe it would be good to start a thread on this in Mozillazine.
(In reply to comment #220)
> Is there som sort of serious issue with getting this fixed? Is this not simple
> fix?

Haven't you read above?  They won't fix it because too many people want them to fix it.

> Maybe it would be good to start a thread on this in Mozillazine.

Please do.  Add a link to it here.
You guys really need to STOP SPAMMING THIS BUG. It only makes it harder for someone to find real information when there's so many useless comments. I don't think you guys really understand what Bugzilla is. It is NOT a place for you to whine about bugs you think need to be fixed. It's a place for DEVELOPERS to share information in order to get bugs fixed.
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
(In reply to comment #222)
> You guys really need to STOP SPAMMING THIS BUG. [...] It is NOT a place for you to
> whine about bugs you think need to be fixed. It's a place for DEVELOPERS to
> share information in order to get bugs fixed.

So, DEVELOPERS: Share some information. Get it fixed. 

IMO, when DEVELOPERS consider user pleas for -- what, 5 years? -- as "whining", a serious attitude adjustment is called for. 

It is obvious to me that no DEVELOPER considers this an important enough problem to take up and fix. It has become an acute embarrassment. IMO.

The result: pop-up tooltips remain an <em>almost useful</em> feature of Mozilla and FireFox.

-R.
Why is the product for this bug Mozilla Application Suite? The exact same bug exists in Firefox and probably other Mozilla-based applications. 
This bug should be a blocker for Firefox 2.0.
For those of you who know how to use bugzilla, this bug is dependent on bug 228673 being fixed - as it shows in both the whiteboard status and the bug dependency field. That bug is in core which is why at affects both Firefox and SeaMonkey.
(In reply to comment #225)
> For those of you who know how to use bugzilla, this bug is dependent on bug
> 228673 being fixed - as it shows in both the whiteboard status and the bug
> dependency field. That bug is in core which is why at affects both Firefox and
> SeaMonkey.
> 

Does that mean that solving bug 228673 would automatically solve the issue of this bug here? I thought this would only be a precondition that would not also solve this bug entirely?
(In reply to comment #226)
> (In reply to comment #225)
> > For those of you who know how to use bugzilla, this bug is dependent on bug
> > 228673 being fixed - as it shows in both the whiteboard status and the bug
> > dependency field. That bug is in core which is why at affects both Firefox and
> > SeaMonkey.
> > 
> 
> Does that mean that solving bug 228673 would automatically solve the issue of
> this bug here? I thought this would only be a precondition that would not also
> solve this bug entirely?
> 
No, it would not automatically solve this issue, just as you said (and I implied) a precondition.
*** Bug 319788 has been marked as a duplicate of this bug. ***
There is a similar problem (as with this bug) with the Bookmark Manager display of bookmark fields with text exceeding the width alloted in the display, e.g. (perhaps) Description, Location and probably others. The text in the display is limited to a single line for each bookmark, with field texts truncated by an ellipsis (...). Hovering the mouse pointer over one of these pops up something that looks like a tool-tip: presented on a single line, edge-to-edge on the screen, if necessary, but again truncated by an ellipsis if the screen is not wide enough. The "tool-tip" is torn down after about 5 seconds of display.

I hope that the tool-tip issue (i.e. this bug) will address the problem in the bookmark manager as described above.

BTW: This problem (w/r/t the bookmark manager) presents an excellent case for:

1. handling a display string of arbitrary length.
2. holding the display as long as the user continues to hover the mouse pointer.

-R.
*** Bug 321888 has been marked as a duplicate of this bug. ***
I think it's not the same bug because in my test case I can't scroll the horizontal scrollbar till the end of it's range and remain there!
*** Bug 325016 has been marked as a duplicate of this bug. ***
(In reply to comment #222)
> You guys really need to STOP SPAMMING THIS BUG. It only makes it harder for
> someone to find real information when there's so many useless comments. I don't
> think you guys really understand what Bugzilla is. It is NOT a place for you to
> whine about bugs you think need to be fixed. It's a place for DEVELOPERS to
> share information in order to get bugs fixed.
> https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
> 

Perhaps the continued activity for this bug in bugzilla for the last 6 YEARS tells you that people want it fixed and it seems to just get ignored.  I'm not seeing any developer banter anywhere and this concerns me.
*** Bug 332122 has been marked as a duplicate of this bug. ***
The solution is in the attachment (the explanation of the tooltip extension behaviour).

https://bugzilla.mozilla.org/attachment.cgi?id=177917&action=view

"[...] in the CASE2, Mozilla wraps it to multi-lines. [...]"

JPG snapshot: http://piro.sakura.ne.jp/xul/doc/popupalt/01.jpg

Could a nice developer just implement that solution TEMPORARILY?
Doesn't seem like a big issue...

THEN, and just THEN, we can start discussing whether the tooltip should stay for six years, or if it should be truncated at 256 chars, etc...

PS: Sorry for spamming (I don't even know if this is spam)
(In reply to comment #235)
> The solution is in the attachment (the explanation of the tooltip extension
> behaviour).

Julian,

I looked at this and saw what he was doing before the attachment was even added - in comment #147.  The real problem is the second part of that attachment, "Second point is a dirty solution for unknown bug of Mozilla."  That's bug #228673.

If I remember correctly, the solution had a few caveats:

1. Single line popups (the most common kind) didn't seem to display correctly; it would resize up but not back down.

2. The solution to the above was to set the height back every time to something smaller (but big enough for a single line, because for a single line it wouldn't get a proper height otherwise), and then let it expand on a timer.  But I wasn't sure how to do this cleanly.

Thinking again on this, though, it might be possible to solve this with a min-height style, and then just setting the height property low.  I should test it again.

3. Because the popup is resized after-the-fact, you can see it when it's a single line, and then you see it suddenly get longer.  This isn't very aesthetically pleasing.

I'm sure there's a much better way to fix this, being bug #228673.

I'd be very interested to know how this behaves on the reflow branch.  It might even be fixed.  I should test that too.

-[Unknown]
I frankly can't believe that this bug is such a big issue, unfixed for years now!

This is important! Keeping web applications from providing helpful information.

What's it keeping from being fixed?
What's required to fix this?
What's missing?
> What's required to fix this?
Can't be much: Someone's already implemented it in an add-on.
https://addons.mozilla.org/firefox/1715/
As mentioned previously, the older extension Popup ALT Attributes (http://www.extensionsmirror.nl/index.php?showtopic=242) also fixes this.
Yes, yes, yes... The solution is there, but apparently the problem is that this solutions are not "elegant" enough to be incorporated at the core. So, you'll have to keep the extensions handy.


(In reply to comment #239)
> As mentioned previously, the older extension Popup ALT Attributes
> (http://www.extensionsmirror.nl/index.php?showtopic=242) also fixes this.
> 
I've added another vote for fixing this bug. I'm amazed that after six years this bug has not been addressed. As a web developer, I make very heavy use of the title tag to provide additional information to readers that does not belong inline with text.  This means Firefox users (myself included) lose out on important information on my site.

In regards to the timing issue, nothing annoys me more than a tooltip that turns off before I've finished reading the tip.  Tool tips should stay on until the cursor has been moved off of the object that initiated the tool tip.  

To me the wrapping of tooltips and the length of display seem to be a basic accessiblity and usability issues that should have been fixed six years ago.
(In reply to comment #241)
> In regards to the timing issue, nothing annoys me more than a tooltip that
> turns off before I've finished reading the tip.  Tool tips should stay on until
> the cursor has been moved off of the object that initiated the tool tip.  

I totally agree. It is incredibly irritating when that happens, while the solution is so simple. This is probably quite easy to fix for someone who knows the codebase.
Happy 6th Birthday son!!  :D
WooHooo!!!!
Though I still think the default behaviour should be changed there is an easily installed exrension for Firefox called "long titles" that works including linebreaks. Unfortunately still with the 5-6 second dissappearing act that "the other" browsere also does. See FF extensions or http://home.etu.unige.ch/~robin0/LongTitles_en.html
Is anyone working on this? Hello! Six years from reporting and no correction. Although this must be very small thing to correct (nl2br anyone?), no traces of  progress visible.

Flags: blocking-aviary1.0- → in-testsuite+
(In reply to comment #244)
> Though I still think the default behaviour should be changed there is an easily
> installed exrension for Firefox called "long titles"...

The problem with the extension solution is that web application programmers can't rely on having this extension available on the average user's computer.

I still vote for having this feature added to the core itself.
(In reply to comment #245)
> Is anyone working on this? Hello! Six years from reporting and no correction.
> Although this must be very small thing to correct (nl2br anyone?), no traces of
>  progress visible.

See bug 228673, that bug needs to be fixed first.
Flags: in-testsuite+
(In reply to comment #245)
> Is anyone working on this? Hello! Six years from reporting and no correction.
> Although this must be very small thing to correct (nl2br anyone?), no traces of
>  progress visible.
> 

I've been following this bug for quite some time now and as a web developer; it is extremely frustrating to see what seems like such a basic usability issue take so many years to get fixed. Being able to rely on title attributes to display properly is incredibly important.  Titles are extremely useful ways to provide additional information about links, as well as definitions of acronyms and technical terms. 

Because of this bug, as a website developer I am left with two options if I want to provide extra "tooltip" information.  I can stick to W3C HTML specifications and accessibility guidelines and accept the fact that Firefox users may not be able to see the entire tooltip or I could implement clunky JavaScripts in lieu of relying on the title attribute, which would create accessibility issues and won't work for browsers that don't support JavaScript.  Even though I use Firefox as my primary browser, I have opted for the first alternative as it does not make sense to break something for one group of users or make it more clunky than necessary just because of this bug in Firefox.

Maybe the solution to getting it to be a priority to fix this bug comes down to web developers forcing this issue by not trying to create clunky work a rounds to this issue and simply using the title attribute as it was intended.  Just maybe if more and more regular Firefox users start feeling the pain of this bug it will finally get fixed. 

With all that MSIE gets wrong when it comes to W3C HTML and CSS specifications, it is really sad to see MSIE get this one right while Firefox gets it wrong.  The Firefox community always scolds web developers for not ensuring their pages work correctly in browsers other than MSIE by validating their code to W3C specifications. This is a two way street; web developers should be able to depend on browser developers to make sure their browsers properly support those same specifications. In this case it means web developers should be able to rely upon tooltips displaying title attributes properly in Firefox.

I've done my part for Firefox users by making sure that my pages validate to W3C specifications and adhere to W3C accessibility guidelines.  It is time that Firefox developers do the same and fix this bug. Six years is too long for a development process that is supposed to be able to more rapidly resolve issues than the closed source model.
(In reply to comment #244)
> Though I still think the default behaviour should be changed there is an easily
> installed exrension for Firefox called "long titles" that works including
> linebreaks. Unfortunately still with the 5-6 second dissappearing act that "the
> other" browsere also does. See FF extensions or
> http://home.etu.unige.ch/~robin0/LongTitles_en.html


Please note that Long Titles is nothing but a repackaging of Popup Alt Attributes without the tooltips on alt texts. It won't solve this bug more than what Popup Alt Attributes did.
(In reply to comment #244)
> Though I still think the default behaviour should be changed there is an easily
> installed exrension for Firefox called "long titles" that works including
> linebreaks. Unfortunately still with the 5-6 second dissappearing act that "the
> other" browsere also does. See FF extensions or
> http://home.etu.unige.ch/~robin0/LongTitles_en.html

"The other" browser actually allows you to keep the tooltip visible indefinitely if you "wiggle" the cursor without moving outside of the object that caused the tooltip to appear.  With the extension, you get wrapping tooltips but they disappear after a few seconds no matter what you do.  But hey - customizable timeouts would be a winner.  It's amusing to follow this thread.  I never would have thought wrapping tooltips was such a source of aggravation.
M.W.: 'See bug 228673, that bug needs to be fixed first.'

I think nobody from regular website developers and users of Firefox is interested that this bug is affected by some other bug. What we see is that Firefox lacks an important usability feature that should have been fixed by long now.

Ken@klb: I couldn't say it better. Thank you for very wise and insightful comment.

The problem is that no developer ever answered the question, when this bug will be fixed. So, I would like to ask Ben Goodger or whoever else from Mozilla Foundation (or the development section) when this bug is going to be fixed?

Finally, I would like to see some responsibility taken by developers and inform us (the community of users, developers and propagators of Firefox) the version of FF where this bug is to be fixed in.
Could part of the problem be that this is marked "normal" importance?  I think it should be escalated to "major" after all this time (six years?!?), as I and I am sure many others would like to create and roll out useful tooltips, but can not do so since people use FireFox.  This affects useability quite a bit, and six years of lowered useability seems pretty major to me.
(In reply to comment #251)
> The problem is that no developer ever answered the question, when this bug will
> be fixed. So, I would like to ask Ben Goodger or whoever else from Mozilla
> Foundation (or the development section) when this bug is going to be fixed?
> 
> Finally, I would like to see some responsibility taken by developers and inform
> us (the community of users, developers and propagators of Firefox) the version
> of FF where this bug is to be fixed in.

You have been told when this bug will be fixed.  Look at the target milestone: "Future".  That means "it will be fixed when someone fixes it".  No releases will be held up for this bug (see comment #131).  No, the Mozilla Foundation has no obligation to tell you things that they don't actually know themselves.  Yes, it's unfortunate that this is not yet fixed, but the various Mozilla employees have decided that it's not quite important enough to block releases, despite its age.  That's their right: their software, their design decisions.

(In reply to comment #252)
> Could part of the problem be that this is marked "normal" importance?  I think
> it should be escalated to "major" after all this time (six years?!?), as I and
> I am sure many others would like to create and roll out useful tooltips, but
> can not do so since people use FireFox.  This affects useability quite a bit,
> and six years of lowered useability seems pretty major to me.

This bug does not *severely* hamper the Web experience of very many users.  It's an annoyance when it does occur, no more than that.  Because there's no particularly easy or obvious workaround, it's not minor, but at least in my opinion, it's not bad enough to be major: the loss of functionality isn't huge and it's possible to work around it, albeit non-obviously/awkwardly.  Timespan has nothing to do with severity (see https://bugzilla.mozilla.org/page.cgi?id=fields.html#bug_severity).

Change it to major if you want.  I doubt it will stay there for long.
Well, I just now tried to change it to "major", but in a bright red background this showed up:  "You tried to change the Severity field from normal to major, but only the assignee or reporter of the bug, or a sufficiently empowered user may change that field."  Looks like we have at least another six years to wait.
(In reply to comment #254)
> Well, I just now tried to change it to "major", but in a bright red background
> this showed up:  "You tried to change the Severity field from normal to major,
> but only the assignee or reporter of the bug, or a sufficiently empowered user
> may change that field."  Looks like we have at least another six years to wait.
> 

In the end it does not matter what its marked as; if the developers say it can wait and nobody else is willing to work on it then it will stay unfixed.

Here's a question - if this means so much too you why not learn how to program C++ and write a patch yourself?
(In reply to comment #252)
> Could part of the problem be that this is marked "normal" importance?  I think
> it should be escalated to "major" after all this time (six years?!?), as I and
> I am sure many others would like to create and roll out useful tooltips, but
> can not do so since people use FireFox.  This affects useability quite a bit,
> and six years of lowered useability seems pretty major to me.
> 

(In reply to comment #253)
> This bug does not *severely* hamper the Web experience of very many users. 
> It's an annoyance when it does occur, no more than that.  Because there's no
> particularly easy or obvious workaround, it's not minor, but at least in my
> opinion, it's not bad enough to be major: the loss of functionality isn't huge
> and it's possible to work around it, albeit non-obviously/awkwardly.

It appears we have a catch-22 here.  Web developers are holding back making real use of the title attribute because it isn't being supported properly in Firefox.  Mozilla developers aren't fixing tooltips because the title attribute isn't being used extensively and this thus isn't a functionality issue to them.

The only answer to this is for web developers to do as I am doing: say "screw it", stop waiting for Mozilla to fix this issue and press forward with using the title attribute as it was intended.  If Firefox users miss out on useful title comments because Firefox's tooltips is broken, it isn't web developers' problem. We can't be expected to wait for ever for "modern", "standards complaint" browsers to fix these types of issues. 

Sometimes the only way to get certain browser issues like this fixed is to make the users of said browser to feel a little pain or inconvenience.
As to the suggestion that I fix the bug myself: it is not such a bad idea, but I already volunteer my time in other ways, such as helping charitable organizations with Web sites (some for free e.g. http://www.semaacademy.org, just finished; others for reduced fee).  I don't think I should need to learn C++ as well as the coding of FireFox in order to have this simple function fixed.  A developer who already knows C++ and FireFox source could do this in a several hours, I would think.  The default behavior should be to have the line length default to + or - a few characters from the current maximum title length display; if there is a white space or punctuation within that + or - a few characters, wrap there, otherwise force a line break at exactly the standard line length in the middle of a word.  There could be a maximum total title length as well.  Not sure if my suggestion matches standards, but again, I specialize in other areas to contribute to society and will not become a Web standards expert, but I do want to add my voice to say that fixing this bug will allow me and others to help charitable organizations by creating more useable Web sites more quickly i.e. for free or for a lower fee.
> David Alexander

If it were that easy this would have been fixed long ago - weather you like it or not the developers obviously have more important things to deal with at the current time. If someone were to volunteer and write a patch themselves, as was done with find as you type in textboxes I believe then this would be fixed. If nobody is willing to do this then thats fine, just wait for one of the developers to do it.

This is a low priority bg because it does not directly block Firefox development - if it does at some time then it will be fixed, otherwise it will wait for a developer to take it.
Just so we get an idea how important this bug is...

Google search for: firefox 45375 : 2100 results
Google search for: mozilla 45375 : 1650 results
*45375 is this bug number.
Google search for "firefox tooltips "does not show" : 11900 results.
Google search for "firefox tooltip "does not show" : 11900 results.

Do these searches at http://www.google.com for yourself and see.

People allover the world complaining about this bug. 
2000 mentioning the specific bug number (most users dont even know what bugzilla is) is very much in my eyes.
Ryan Jones: Thank you for your Wise advice.

In case you haven't noticed: not everybody discussing the bug here wants to learn C++ just because there is an unfixed bug six years old affecting usability of Firefox. Yes, there are even people donating their time elsewhere and not necessarily spending it, working on Firefox.

BUT: There certainly are people who would be happy to volunteer. Maybe you (and the rest of debaters making things up why it is impossible to fix this in any near future) should just read through the older comments and for example find the post #91 From Bart Kelsey dated 2003-09-03 13:57 PDT (yes, almost thre years old):
--
I'm interested in attempting to fix this bug...  I'm a competent C/C++
programmer with no experience with the Mozilla code base, so I'd appreciate it
if someone could point me to the part of the code (file and lines) where
tooltips are handled, and I'll take a look.
--

I appreciated if you would spend your time helping this particular volunteer to understand Mozilla code base, so he can make his work done (instead of giving advices on learning C++ to XHTML coders). Thank you.



(In reply to comment #260)
> I'm interested in attempting to fix this bug...  I'm a competent C/C++
> programmer with no experience with the Mozilla code base, so I'd appreciate it
> if someone could point me to the part of the code (file and lines) where
> tooltips are handled, and I'll take a look.

Dan, see bug 228673.

Please, from now on, only add a comment if you have a solution, by attaching a patch or adding technical comments that would help solve this bug. 
It is now very well known that there are a lot of people who find this an important bug to fix, but clearly that hasn't helped solving this bug (otherwise this would have been fixed 5 years ago).
(In reply to comment #260)
> In case you haven't noticed: not everybody discussing the bug here wants to
> learn C++ just because there is an unfixed bug six years old affecting
> usability of Firefox. Yes, there are even people donating their time elsewhere
> and not necessarily spending it, working on Firefox.

Well, everyone is busy.  Let's say this is hugely important, but what about fixing security bugs?  What about making Firefox recover better from crashes?  What about simplifying the code and cleaning up rendering/incrememental reflow bugs?

I've tried to fix/workaround this bug.  In fact, I found a way to get (very kludgey) to work myself and ran with it for a while fairly successfully.

But it had minor problems.  Sometimes, due to my kludge, tooltips wouldn't come up.  Couldn't determine exactly why.  Now I don't run with it anymore, because, well, if I ever want to read a long tooltip I can just right click -> Properties.  It always works this way.  No patching, no problems, life is easier.

If you look at the bug referenced, there are some problems that are difficult to work around.

I am actually very hopeful that the changes on the reflow branch will fix that bug, which will make fixing this bug possible.  That's being worked on, last I knew... which may mean that, in other words, this bug is being worked on after all.

Stay calm.  Don't Panic.  Consult the Guide if you feel the universe closing in on you.

Anyway, I never got time to test it as I mentioned I wanted to in comment #236.  Maybe someone who has time and feels this is important can.  It doesn't take C++ knowledge afaik.

Please forgive the unending bugspam.

Thanks,
-[Unknown]
> well, if I ever want to read a long tooltip I can just right click ->
> Properties.  It always works this way.  No patching, no problems, life is
That sounded like a good suggestion for the (long) "mean time".  But when I tried it, I found that if the title included linebreaks, the rest of the title is not shown. (The dialog box had to be maximized to even show that far.)
Why not setting up a bounty programme? All of you complaining about this bug give a few dollars/euros/other -- and find other donators -- to pay a developer to fix it.
Severity: normal → major
http://www.webdevout.net/tidings/2006/09/02/the-poorly-supported-title-attribute/

> Firefox has perhaps the most disruptive bug (45375), which limits the tooltip text to a small number of characters on a single line. Progress on fixing that bug is blocked by another bug (228673) relating to the calculation of tooltip heights. Firefox also has several problems with newlines, carriage returns, and tabs in the source HTML and doesn’t convert newline character references into line breaks. This is overall the worst implementation of the title attribute of all major browsers.
(In reply to comment #265)
> http://www.webdevout.net/tidings/2006/09/02/the-poorly-supported-title-attribute/
> 
> > Firefox has perhaps the most disruptive bug (45375), which limits the tooltip text to a small number of characters on a single line. Progress on fixing that bug is blocked by another bug (228673) relating to the calculation of tooltip heights. Firefox also has several problems with newlines, carriage returns, and tabs in the source HTML and doesn’t convert newline character references into line breaks. This is overall the worst implementation of the title attribute of all major browsers.
> 

How sure are we he fully understands the spec?  Based on my reading of it, it's not clear whether #&10; really should be treated differently from a \n in this case.

From http://www.w3.org/TR/html401/types.html#type-cdata we see:
---
CDATA is a sequence of characters from the document character set and may include character entities. User agents should interpret attribute values as follows:

    * Replace character entities with characters,
    * Ignore line feeds,
    * Replace each carriage return or tab with a single space.
---

If the interpreting is done in that order, the entity &#10; gets replaced with \n, and then the \n gets clobbered.  This seems to be the behavior we currently use.  For example, data:text/html,a&#32;&#32;&#32;b only has one space between a and b.  Same for tabs - try data:text/html,a&#9;&#9;&#9;b and notice that the 3 tabs got converted to a single space.
Chris, that is correct.

Given that, only issues with long tooltips (which this bug is about) and display time remain. Although last time I checked, I think U+000A characters were shown as weird characters instead of being converted to spaces and collapsed.


~Grauw
The way at least XML defines it, &#10; in the attribute value should in fact result in a newline when all is said and done. The HTML 4.01 specification itself isn't clear about this (the list it gives is an unordered list, not an ordered list, so it doesn't necessarily represent an ordered sequence of actions). I assume that the HTML spec is just summarizing rules already specified in the SGML standard. If someone here has a copy of the SGML standard, that could help clear up the issue.

Considering that XML is supposed to be an application of SGML, I would assume this rule must be compatible with the way it works in SGML in general.

Here is the relevant link: http://www.w3.org/TR/REC-xml/#AVNormalize
Regarding the duration of a tooltip, I rephrase my comment #137.  

The duration should be computed from the length of the character string:  
    (a + b*n/5)
where a and b are each some number of seconds and n is the number of characters.  The division by 5 is based on a very old rule of thumb that the average word is 5 characters (derived from determining the speed of a typist in words per minute by counting the total number of characters -- not words -- typed during a timed interval).  a is the latency for recognition, the time required before the user realizes there is a tooltip to read.  b is the speed (words per second) at which text can be read with comprehension.  

The formula should be evaluated each time a tooltip is to be displayed without any attempt (as suggested in other comments) to store the computed duration.  With today's processor speeds, a tooltip could be displayed while the duration is being computed since the time to complete that computation would likely be less than the latency (the a term).  

While my original comment gave a = 5 sec and b = 1 sec, the actual values should be based on formal studies.  While I don't suggest the users should be allowed to set a and b explicitly, they might be allowed to choose "short", "medium", and "long" durations, each of which results in a different pair of a and b.   
(In reply to comment #269)
> While my original comment gave a = 5 sec and b = 1 sec, the actual values
> should be based on formal studies.  While I don't suggest the users should be
> allowed to set a and b explicitly, they might be allowed to choose "short",
> "medium", and "long" durations, each of which results in a different pair of a
> and b.   
> 

I think you could also consider the allowing users to set the duration as an accessibility feature. Older people especially have to take time to read things, when the duration is short they may have problems so I guess it would be a good idea.
(In reply to comment #269)

Great idea.
(In reply to comment #269)
> The division by 5 is based on a very old rule of thumb that the
> average word is 5 characters

This is probably true only for average english words, but is very likely to be wrong in lot of other languages.
My dream specification: user can use preferences to toggle between four behaviors: tag popups always off, always on (regardless of mouse hover, centered on image), popups display for 2 or 3 seconds after mouse hover (default, current spec), or popups displayed on mouse hover whenever and only so long as ALT is pressed.*

*ALT or some other key or combination of keys

The last would be my preferred behavior, so I can take as long as I like to read the tag at first, then get it out of the way for good.  But if I could just toggle between always off and always on with a quick keyboard shortcut, it would amount to the same thing.

(The IE ability to keep tags popped up with a mouse wiggle as mentioned earlier is a workaround, not a feature, and as such, it's an imprecise solution.  As long as we're fantasizing that this will ever get addressed, I thought I'd throw out my $.02.)
(In reply to comment #273)

I would prefer: (for ALT, read any chosen key or combination)

1. An option to set display time, zero to whatever. Hover starts the display and the timer.
2. Display terminated by mouse-out or timer 
3. ALT key toggles display (mouse hover target) on/off (and cancels timer, if active)

It may be desirable to provide an option that somehow distinguishes targets for which there are latent tips, perhaps by outlines.

I think that these would allow a range of actions broad enough to satisfy anyone. 

-R.
I don't understand the point in this whole "duration" discussion. Maybe I missed something, but can someone explain to me why a tooltip needs to disappear at all if the mouse isn't moved away from the element? Shouldn't it be obvious that sudden unexpected and uncalled-for disappearance is annoying? Shouldn't it also be obvious that, given that you can make the tooltip disappear by moving the mouse away, there is no need to have it disappear automatically?

A key to make tooltips disappear without having to move the mouse might be nice, but a key to keep it displayed and stop it from disappearing?? Come on! Keeping it displayed should be the default.
(In reply to comment #275)
> I don't understand the point in this whole "duration" discussion. Maybe I
> missed something, but can someone explain to me why a tooltip needs to
> disappear at all if the mouse isn't moved away from the element? Shouldn't it
> be obvious that sudden unexpected and uncalled-for disappearance is annoying?
> Shouldn't it also be obvious that, given that you can make the tooltip
> disappear by moving the mouse away, there is no need to have it disappear
> automatically?
> 
> A key to make tooltips disappear without having to move the mouse might be
> nice, but a key to keep it displayed and stop it from disappearing?? Come on!
> Keeping it displayed should be the default.
> 

I agree, the most annoying thing for me is when tool tips disappear prematurely or stick around too long. I've always thought that tooltips (whether part of Windows GUI or a webpage) should stay visible as long as the cursor is over the object the tooltip belongs to.  Once the cursor is removed from the object in question then the tooltip should disappear.  This seems like such an obvious thing that I've never understood why this isn't the way all tooltips work in general.  The little popups used on Yahoo News is an example of "tooltips" mostly done correctly.
> I've always thought that tooltips (whether part of
> Windows GUI or a webpage) should stay visible as long as the cursor is over the
> object the tooltip belongs to.  Once the cursor is removed from the object in
> question then the tooltip should disappear.

Ok, this is my new dream spec, it's as functional and far more elegant than my previous comment.
I also like the simplicity of mouse over object == tooltip shows.  There is one problem, however: for some smaller objects, you can not always tell if the mouse is still over the object because the tooltip may be covering the object, and tooltips do not always go away when desired.  Also if there is text in the object you may want to again show the text without large movement of the mouse for larger objects.  The tooltip could be positioned right over the text, and moving away a large enough distance for a larger graphic object could be awkward and non-intuitive.

My spec would be, if the mouse goes over the object for a certain length of time, then tooltip display starts.  If the mouse then moves more than a certain number of pixels from the position where the tooltip started (or alternatively from a point where the mouse stops moving after tooltip display has started, to avoid a problem with mouse momentum causing the tooltip to start showing and disappear before the user has a chance to respond), the tooltip immediately disappears.  This allows the user to stay over the object, see the tooltip, and have it disappear, with minimal complexity.  Whether some behaviors could be programmed beyond the above is a judgment call.
should the tooltip disappear after a period of time, or should it stay on until I remove the cursor?

should we vote on this subject?

how is it handled when opinions differ?
(sorry, I'm new here)
1) I'm sure it would be appreciated if discussion of tooltip duration were moved to its own bug.  It's not really relevant to this bug, whose discussion has by now become a textbook example of How Not To Use Comments On Bugzilla.

2) Final decisions will be made by the developers (specifically the developers who are high up in the pecking order), not by vote, although of course they may be influenced by what people want.  And, of course, you could always write an extension if you felt like it.
>It's not really relevant to this bug, whose discussion
has by now become a textbook example of How Not To Use Comments On Bugzilla.

Maybe, because developers are not responding and this bug's been here stuck for last six years?

> Final decisions will be made by the developers (specifically the developers
who are high up in the pecking order)

Developers should respect their users and act accordingly. This applies to usability as well.
I would think the volume of comments on the bug might act as a positive, though certainly not decisive, influence on what the developers decide to work on.  My guess based on some comments about complexity for the bug fix is that the perceived difficulty of making the fix is relatively large compared with the perceived seriousness of the bug.

As far as the seriousness of the bug, it is true this does not prevent Firefox from showing Web pages, but it does affect usability quite seriously and adds significant development time to make certain valuable behaviors (e.g. pop-up help) work well.
(In reply to comment #282)
> As far as the seriousness of the bug, it is true this does not prevent Firefox
> from showing Web pages, but it does affect usability quite seriously

Right. Not being able to display long tooltips impairs functionality. If Firefox would not be able to display CSS rules, someone would immediately have fixed it. Compared to this, missing long tooltips is even more serious as it hides valuable content.
(In reply to comment #281)
> Developers should respect their users and act accordingly.

This statement applies to developers that are on your pay-roll. I think, for open source projects this statement and the attitude it conveys rather deters developers.
I do not agree on principle. Unusable (as "use" in usability) open source software won't be used.

I don't think this is the critical error that discourages users, but still affects their use of websites strongly.

I am an open source software developer as well, and if I wouldn't be able to comprehend what users' needs are and why users use software in this way or the other, users will be discouraged to use it.

I understand that this bug depends on some other bug, but why developers of Firefox does not include something like the extension code (AltTooltip or how is it called) in the core until the bug is properly fixed? I have been using AltPopup extension for something over a year and it works without glitch. (at least visually and functionally) 
Since the discussion here is already non-technical I feel like I need to say that - I'm a neutral user who wants this bug fixed just like anyone else, but I sense a degrading attitude from some of the users, more so than from the developers.
You think Mozilla developers aren't going a good job in organizing their project? There are ways to express your thoughts with a different attitude. Open source developers do what they do because they care, and not for selfish purposes. The fact they're doing something for you doesn't mean they OWE you anything, they are doing you a FAVOR.
Please, try to remember that.
Again I've hesitated to respond here, but since I am the original reporter of this (2nd grader age) issue, I feel I can justify a non-technical response.  I've dug into the code myself for other bugs in the Mozilla codebase, I thought I found where the issue resided, and offered a suggested solution. I got the same response there, then fix it yourself. I cannot do active C++ devt, of which much of this codebase is written.  I then depend upon the Mozilla devt community to do this work.  Should I spend my days finding the bug source and offer a solution again, only to hear, "then fix it".  

Dataloss is dataloss, regardless of what anyone says to justify it. 
Attached patch some codeSplinter Review
Assignee: iann_bugzilla → cst
Attachment #237514 - Flags: review?(neil)
Maybe someone will be more willing to look at this after the reflow branch lands anyway, it may possible fix / help fix bug 228673 whihc is currently blocking this.

-- Ryan Jones.
Comment on attachment 237514 [details] [diff] [review]
some code

I don't like this as a solution for trunk, but as a workaround for branch, limited to browser tooltips and cleaned up, then I think it would be OK.

>+      // My interpretation of the spec implies this is the behavior we want
>+      tipNode.setAttribute("label", t.replace(/\n/g,"").replace(/\r/g," "));
Even if our parser is changed to reject newlines I think we should respect newlines in title attributes set via DOM methods.

>+      <xul:hbox anonid="tooltip-hbox" xbl:inherits="xbl:text=label,crop"></xul:hbox>
Don't bother. Just get the original label from the tooltip. Also use />

>+        hbox.setAttribute("height", 0);
If removeAttribute("height") doesn't work then still use .height anyway.

>+        // The label also remembers things, so blow it away.
Can we not put the height on the label and solve both problems at once?

>+        if (hbox.firstChild)
hasChildNodes()

>+        label.appendChild(document.createTextNode(hbox.getAttribute("text")));
Or set label.textContent

>+        label.setAttribute("class", "tooltip-label");
>+        label.setAttribute("style", "white-space: -moz-pre-wrap;");
Use properties...

>+        label.setAttribute("flex", 1);
>+        label.setAttribute("crop", "right");
Useless, no?

>-  max-width: 40em;
Why do we have to move this?

>+hbox[anonid="tooltip-hbox"] {
>+  max-width: 40em;
>+}
Will need browser.css modifications...
Attachment #237514 - Flags: review?(neil) → review-
I run a largish webcomic which, like many webcomics, puts commentary or an additional punchline in the comic's title-text.  I want to know where I can send money to have this fixed, because it's ridiculous.  My readership is about 55% Firefox users, and while the constant emails saying "Why can't I see the title-text on your comics?" are annoying, what's much more problematic are all the readers who don't take the time to look into it and just assume Firefox (or worse, my website) is broken.

The webcomic community is really tired of this bug.  I can't really do it myself as I am not much of a programmer, but I assume the code to fix it is already in the many extensions.  If it's coders you need, I can solicit readers to help out.  Just please, someone tell me what to do.  Let me know where I can put a bounty on this bug, who I can email or call to hassle about this, or anything else I can do.  Whining about it for the past several years hasn't seemed to fix it.

I don't know much about the Mozilla bug-fixing process, but this seems ridiculous.  Has this seriously been an unfixed issue for over six years now?  Do I need to start recommending my site's readers away from Firefox, or should I have them canvass all the main Mozilla developers via email?

-- Randall Munroe
-- rmunroe@gmail.com
Randall Munroe - right now money won't get much done here. This bug relies up on bug #228673 which won't be fixed until the reflow branch lands, after Gecko 1.9 Alpha. This means it will have to wait at least that long to be fixed. Maybe a developer will be more willing to look at it then, maybe not but only time will tell so maybe wait until reflow lands before trying to do anything?
(In reply to comment #292)
> Randall Munroe - right now money won't get much done here. This bug relies up
> on bug #228673 which won't be fixed until the reflow branch lands, after Gecko
> 1.9 Alpha. This means it will have to wait at least that long to be fixed.
> Maybe a developer will be more willing to look at it then, maybe not but only
> time will tell so maybe wait until reflow lands before trying to do anything?
> 

For those of us who don't keep up with day to day development nor which version of Gecko is currently at, what type of timeframe are we looking at for 1.9 Alpha landing? 

In addition to the webcomics mentioned above, another place that the TITLE attribute is used heavily is on forum software like vBulletin so that users can read summaries of threads in thread listings. This means that Firefox users are losing a major piece of functionality on those countless forums.

I have seen some comments recently that seem to think that this issue could be fixed without waiting for bug #228673.  Has anyone seriously evaluated this possibility recently or are Mozilla developers just assuming that a dependency that was noted years ago is gospel?
(In reply to comment #293)
> For those of us who don't keep up with day to day development nor which version
> of Gecko is currently at, what type of timeframe are we looking at for 1.9
> Alpha landing? 
> 

http://wiki.mozilla.org/Firefox3/Schedule

October - November this year.

> I have seen some comments recently that seem to think that this issue could be
> fixed without waiting for bug #228673.  Has anyone seriously evaluated this
> possibility recently or are Mozilla developers just assuming that a dependency
> that was noted years ago is gospel?
> 

The Mozilla dev's know what they are talking about, if they think its dependent then I very much doubt that anyone will look at it until the reflow lands and bug #228673 is fixed. If you want to discuss this I guess you could log into IRC and talk to the devs yourself and get their opinions.
(In reply to comment #291)
> I run a largish webcomic which, like many webcomics, puts commentary or an
> additional punchline in the comic's title-text.  I want to know where I can
> send money to have this fixed, because it's ridiculous.  My readership is about
> 55% Firefox users, and while the constant emails saying "Why can't I see the
> title-text on your comics?" are annoying, what's much more problematic are all
> the readers who don't take the time to look into it and just assume Firefox (or
> worse, my website) is broken.
> 
> The webcomic community is really tired of this bug.  I can't really do it
> myself as I am not much of a programmer, but I assume the code to fix it is
> already in the many extensions.  If it's coders you need, I can solicit readers
> to help out.  Just please, someone tell me what to do.  Let me know where I can
> put a bounty on this bug, who I can email or call to hassle about this, or
> anything else I can do.  Whining about it for the past several years hasn't
> seemed to fix it.
> 
> I don't know much about the Mozilla bug-fixing process, but this seems
> ridiculous.  Has this seriously been an unfixed issue for over six years now? 
> Do I need to start recommending my site's readers away from Firefox, or should
> I have them canvass all the main Mozilla developers via email?
> 
> -- Randall Munroe
> -- rmunroe@gmail.com
> 

Maybe just because I had to waste time reading your useless comment and the useless replies that followed, I should delay checking in whatever fix I eventually get reviewed.  Did you really think the TWO HUNDRED NINETY comments before yours hadn't made it obvious to us that people want this?
Whiteboard: [seamonkey. blocked by bug 228673.] → DO NOT COMMENT! THIS IS NOT A FIREFOX BUG! [seamonkey. blocked by bug 228673.]
I am not bothered by the repeated heartfelt requests as much as I am by the infantile, unprofessional ("I'll take my marbles home if people don't shut up!") responses to them.
(In reply to comment #295)
> (In reply to comment #291)
> > I run a largish webcomic which, like many webcomics, puts commentary or an
> > additional punchline in the comic's title-text.  I want to know where I can
> > send money to have this fixed, because it's ridiculous.  My readership is about
> > 55% Firefox users, and while the constant emails saying "Why can't I see the
> > title-text on your comics?" are annoying, what's much more problematic are all
> > the readers who don't take the time to look into it and just assume Firefox (or
> > worse, my website) is broken.
> > 
> > The webcomic community is really tired of this bug.  I can't really do it
> > myself as I am not much of a programmer, but I assume the code to fix it is
> > already in the many extensions.  If it's coders you need, I can solicit readers
> > to help out.  Just please, someone tell me what to do.  Let me know where I can
> > put a bounty on this bug, who I can email or call to hassle about this, or
> > anything else I can do.  Whining about it for the past several years hasn't
> > seemed to fix it.
> > 
> > I don't know much about the Mozilla bug-fixing process, but this seems
> > ridiculous.  Has this seriously been an unfixed issue for over six years now? 
> > Do I need to start recommending my site's readers away from Firefox, or should
> > I have them canvass all the main Mozilla developers via email?
> > 
> > -- Randall Munroe
> > -- rmunroe@gmail.com
> > 
> 
> Maybe just because I had to waste time reading your useless comment and the
> useless replies that followed, I should delay checking in whatever fix I
> eventually get reviewed.  Did you really think the TWO HUNDRED NINETY comments
> before yours hadn't made it obvious to us that people want this?
> 

Interesting, I hope you don't represent the rest of the devs looking at this.  That's quite childish.
(In reply to comment #295)
> 
> Maybe just because I had to waste time reading your useless comment and the
> useless replies that followed, I should delay checking in whatever fix I
> eventually get reviewed.  Did you really think the TWO HUNDRED NINETY comments
> before yours hadn't made it obvious to us that people want this?

How does it help Firefox or Firefox users to hold back fixes out of spite.                                                                                                                                                                                                                        Firefox is in a pitched battle against MSIE for the hearts and minds of users.  Yes there are 290 comments but they have been over a period of six years and the problem has yet been resolved -- in part because people didn't see this to be a "major" issue.

The comment in question is simply providing more evidence that this is a major usability issue and the bugs involved deserve to be elevated to a higher level of priority.  Maybe six years ago a broken TITLE attribute wasn't a big deal because it wasn't heavily used; however, today it is.  For many years people have been told that the ALT attribute isn't to be used to provide "tooltips" to users thus Firefox, Mozilla and Opera ignore the ALT attribute if images load correctly.  Now developers are finally using the TITLE attribute properly as defined by W3C only to find that 10%+ of users can't properly access comments in the TITLE attribute because of a six year old unfixed bug in the browser of their choice.

IE7 is Microsoft's effort to reclaim lost territory.  The last thing Firefox needs is to start losing gained ground because functionality issues like this start turning users off. This bug is a major issue.  Instead of sniping at good willed individuals who really care, those with the technical ability to fix this bug should do something about it. This way those of us without the necessary technical skills can continue to evangelize for Firefox without bugs like this becoming roadblocks to adoption by users and support by web developers.
(In reply to comment #295)
> Maybe just because I had to waste time reading your useless comment and the
> useless replies that followed, I should delay checking in whatever fix I
> eventually get reviewed.  Did you really think the TWO HUNDRED NINETY comments
> before yours hadn't made it obvious to us that people want this?

Please stop clogging up the comments with useless "please stop clogging up the comments with useless messages" messages.
(In reply to comment #298)
> (In reply to comment #295)
> > 
> > Maybe just because I had to waste time reading your useless comment and the
> > useless replies that followed, I should delay checking in whatever fix I
> > eventually get reviewed.  Did you really think the TWO HUNDRED NINETY comments
> > before yours hadn't made it obvious to us that people want this?
> 
> How does it help Firefox or Firefox users to hold back fixes out of spite.     

I don't personally care much whether or not people use Firefox.  This bug is for SeaMonkey.  Your Firefox complaints belong somewhere else: bug 218223.  Go whine there with the same complaint as hundreds of other people, not here.

> Instead of sniping at good
> willed individuals who really care, those with the technical ability to fix
> this bug should do something about it

You're right.  The $0.00 per hour I'm being paid to fix bugs does mean I should fix your pet bug rather than a different bug.  I mean, if we just fixed this one bug, you'd sing praises on street corners about the wonder that is Firefox, and so would every other user.  And that would really make me happy.</sarcasm>  Apparently you (with your good intentions) don't care enough to read all the comments on a bug before commenting, or you'd see that you're far from the only person who wants this and has given various "justifications" for why the feature should be added, and how ridiculous it is to have this bug open for [1-6] years.  What's so much more special about you and your 293rd comment?  Maybe if you weren't lazy and you had read the bug, you'd have seen that there *was* some recent developer activity.  Developers do care a little.  Whining makes us (well, me, at least) care less.

> This bug is a major issue.

As someone else pointed out in an earlier comment, in the >6 years this bug has been open, you could have learned to program and fixed it yourself.  You'd think if this bug was that serious, *somebody* would have done that.
(In reply to comment #300)
> I don't personally care much whether or not people use Firefox.  This bug is
> for SeaMonkey.  Your Firefox complaints belong somewhere else: bug 218223.  Go
> whine there with the same complaint as hundreds of other people, not here.

Actually isn't it a Gecko bug that affects SeaMonkey AND Firefox?  If this is the case, wouldn't fixing this bug in Gecko also fix the bug in both places? It was even pointed out above that the soonest this bug could be addressed was in Gecko 1.9 alpha.

I'm not the most fluent on the technical aspects of Gecko vs. Firefox vs. SeaMonkey, but I've always been under the impression that all rendering issues were Gecko.

Also if you look at the history of bug 218223 I think you will see that it was at one point closed as a duplicate of this bug.  Does it make sense to have two bug tracks for this issue when it really affects the core engine used by the two products in question?
(In reply to comment #301)
> I'm not the most fluent on the technical aspects of Gecko vs. Firefox vs.
> SeaMonkey, but I've always been under the impression that all rendering issues
> were Gecko.

However, this is not a rendering issue.  The problem which causes it may or may not be, but changing the way tooltips are displayed is a user-interface issue, and so there are separate bugs for Firefox and SeaMonkey.

I really would enjoy seeing this bug fixed.  However, before you complain about it not being fixed yet, consider this:

A casual bugzilla search yields about 10,000 bugs that are open for Mozilla/Firefox/Gecko/etc. (compared to 50,000 fixed.)  For example, some are about (potential) memory leaks.  A lot of people care about these bugs a lot too, and think they should be fixed.

I guarantee that if you asked any given developer, he or she could name at least one bug he or she felt was more important than this bug, out of all those 10,000.  And that's probably the bug he or she is working on.

Unfortunately, there aren't 10,000 developers.  Or even 1,000.  There are less.  So some bugs must wait, inevitably.

This is why it annoys developers when you complain such; you're telling them how to do their job.  They make the call on what's important, and they do so because they really know what's important.

You, users, know what you want... but you wouldn't walk into an emergency room and start barking orders about what order patients should be treated in - would you?  That is the job of a doctor, nurse, or similar - and you would not tell them how to do their job.

Please, let the developers do what they do best.  In the end, it will be the best for Firefox, SeaMonkey, and all Mozilla products.  This bug will be fixed eventually... and no faster if you complain.

Sorry for the spam.

-[Unknown]
> and so would every other user.  And that would really make me happy.</sarcasm>

You forgot to open the <sarcasm> tag, you don't validate.
Everyone, shut up and wait.

The steady stream of pointless comments is getting very tiresome.
(In reply to comment #304)
...or just quit considering Firefox...
(In reply to comment #305)
> ...or just quit considering Firefox...

...or consider fixing it yourself.
I tried and I failed, but at least I tried. That’s the difference in me and some, including all the right wingers who are attacking me now. They ridiculed me for trying. They had 6 years to try and they didn’t…I tried.
(sorry, couldn't resist :P, this comment is as useless as most of the other comments in the bug)
[from various posters]

>This is why it annoys developers when you complain such; you're telling them
>how to do their job.  They make the call on what's important, and they do so
>because they really know what's important.

Well, I'm letting them know about a large userbase that's experiencing a particular bug so they can include that in their judgement.  It seemed odd how much this particular bug was talked about in my circles without being fixed, and I wondered if the problem might just be that it was a big problem only in relatively closed communities.  So I just wanted to add my comment, on behalf of the many, many people who email/message me about this and don't know where to report their problem.  If this doesn't change the developers' judgement on the importance of this bug, that's fine; their call, they know the development situation, I don't.

>You'd think if this bug was that serious, *somebody* would have 
>[fixed it by now].

So would I!  Which is why I'm surprised it hasn't been, and I'm trying to learn more on behalf of my readers, the majority of whom who don't know **** about open source development (not that I know much more).

>As someone else pointed out in an earlier comment, in the >6 years this bug has
>been open, you could have learned to program and fixed it yourself.  

I thought could try to talk to some developers more familiar with the problem and ask them if I can do anything to help, either with money or by getting in touch with additional programmers.  Thank you for your practical advice to change my career.

>You're right.  The $0.00 per hour I'm being paid to fix bugs does mean I should
>fix your pet bug rather than a different bug.  I mean, if we just fixed this
>one bug, you'd sing praises on street corners about the wonder that is Firefox,
>and so would every other user.  And that would really make me happy.</sarcasm> 

Yeah, pretty much.  I want to use my site and readership to further the cause of this browser, free software and related issues.  The browser not working on the site is a significant obstacle to this.  I'm not telling you what to do.  I am politely. Sharing.  My experience.  And I am asking.  What I can do.  To help.  

>Maybe just because I had to waste time reading your useless comment and the
>useless replies that followed, I should delay checking in whatever fix I
>eventually get reviewed. 

Thank you for the insight into the development process.  I will keep this in mind when readers ask ab[from various posters]

>This is why it annoys developers when you complain such; you're telling them
>how to do their job.  They make the call on what's important, and they do so
>because they really know what's important.

Well, I'm letting them know about a large userbase that's experiencing a particular bug so they can include that in their judgement.  It seemed odd how much this particular bug was talked about in my circles without being fixed, and I wondered if the problem might just be that it was a big problem only in relatively closed communities.  So I just wanted to add my comment, on behalf of the many, many people who email/message me about this and don't know where to report their problem.  If this doesn't change the developers' judgement on the importance of this bug, that's fine; their call, they know the development situation, I don't.

>You'd think if this bug was that serious, *somebody* would have 
>[fixed it by now].

So would I!  Which is why I'm surprised it hasn't been, and I'm trying to learn more on behalf of my readers, the majority of whom who don't know **** about open source development (not that I know much more).

>As someone else pointed out in an earlier comment, in the >6 years this bug has
>been open, you could have learned to program and fixed it yourself.  

I thought could try to talk to some developers more familiar with the problem and ask them if I can do anything to help, either with money or by getting in touch with additional programmers.  Thank you for your practical advice to change my career.

>You're right.  The $0.00 per hour I'm being paid to fix bugs does mean I should
>fix your pet bug rather than a different bug.  I mean, if we just fixed this
>one bug, you'd sing praises on street corners about the wonder that is Firefox,
>and so would every other user.  And that would really make me happy.</sarcasm> 

Yeah, pretty much.  I want to use my site and readership to further the cause of this browser, free software, and related issues.  The browser not working on the site is a significant obstacle to this.  I'm not telling you what to do.  I am politely. Sharing.  My experience.  And I am asking.  What I can do.  To help.  

>Maybe just because I had to waste time reading your useless comment and the
>useless replies that followed, I should delay checking in whatever fix I
>eventually get reviewed. 

Thank you for the insight into the development process.

-- Randall Munroe
Oh ****, apologies.  Looks like I had a pasting mishap after revising things in an easier-to-view window.  Intended comment follows the "[from various posters]" in the middle.
Sorry for the bug spam, but could we cut it out with the bug spam?  I've got like 300 friggin' emails in my inbox from this bug...

If someone could point to the source code in question that needs to be fixed, that would help a bunch.  If someone already did so, sorry for asking.
(In reply to comment #309)
> Sorry for the bug spam, but could we cut it out with the bug spam?  I've got
> like 300 friggin' emails in my inbox from this bug...
> 
> If someone could point to the source code in question that needs to be fixed,
> that would help a bunch.  If someone already did so, sorry for asking.
> 

Look at any of the attached patches, or the patches on the bug this depends on.
Just one more note about why extensions don't seem appropriate to substitute TITLE texts: They can't cross frames.
I am going to comment on this bug.  PLEASE DON'T EXPLODE EVERYONE.

I know that I am just another voice asking for this bug to be fixed, BUT!  For the past week I've been linking on my website to one of the many third-party patches to fix this behaviour that have sprung up in the 5+ years this bug has been active.  I have received several emails from Firefox users thanking me (thanking me!) for "fixing" this bug for them, as it had annoyed them daily for a long time and they just assumed it was unfixable, or that they were SUPPOSED to right click on the image and select image properties if they wanted to read the title text, because that is the way the internet works.

This was a nice change from the one email per week I usually get, asking me why my website is broken in Firefox.

Like Randall above, I have a pretty popular webcomic that uses title text.  What I am trying to say here is that yes the bug is old and yes there are patches but until it's fixed in the main source, people will just assume "Oh that's a Firefox thing" and if there's enough Firefox features to keep them using the browser, they'll stay, and if not, they'll leave and go back to some other browser that actually works the way they expect.  Also, this is a usability bug that results in lost information for all but the most determined users, and I think it's affecting more people than some of the commenters here realize.

please don't get mad i just wanted to share my experience and to let people know that demand for getting this bug fixed is pretty wide-spread across regular people, not just the hard-core users

i hope we're still cool
The reason why this bug shouldn't be commented on any more is that A FIX IS UNDERWAY BUT NOT BEFORE FIREFOX 3.0

Why the hell is this SO difficult to understand?

So: We KNOW that this is important for many people. There's no need for even more stories.
sorry for sharing
(In reply to comment #313)
> The reason why this bug shouldn't be commented on any more is that A FIX IS
> UNDERWAY BUT NOT BEFORE FIREFOX 3.0
> 
> Why the hell is this SO difficult to understand?

Maybe because no one has explicitly stated in this bug thread that it was going to be fixed in Firefox 3.0.  It isn't like it is common knowledge when this will be fixed outside firefox/gecko developer circles.  Also your comment leaves this issue open ended as you say "not before Firefox 3.0" but this doesn't mean it will be fixed after Firefox 3.0. Instead it sounds more like another brush off trying to get people to forget about this issue.

> So: We KNOW that this is important for many people. There's no need for even
> more stories.

Yelling at concerned users is a great way to win converts to Firefox.
Firefox 3.0 - does that mean another 3 to 5 years? Great. Just imagine, where the other browsers would be at that time.
>Firefox 3.0 - does that mean another 3 to 5 years?
>Great. Just imagine, where the other browsers would be at that time.

Please don't make such statement without at least some minimal attempt to research.
See http://wiki.mozilla.org/Firefox3/Schedule
To summarize every above comment:

1) This bug is very important.
2) Official fix is anticipated by May 2007, with FF 3.0 (earlier in beta).
3) Due to the nature of the bug, earlier progress is unlikely, if not impossible.
4) There are some workarounds that have generated great praise, like the Long Tooltips Extension.
5) Pretty soon, no one will ever use FF again because of this bug.
and
6) Pretty soon, no one will ever develop FF again because of the complaints about the bug on this forum.
(5 & 6 are still subject to some debate, but everyone's agreed that something horrible is imminent.)
(In reply to comment #318)
> To summarize every above comment:
etc...

Hehe, best comment yet:-)

If this bugdescription had to be of any good use for the developers, then all comments should be constructive and informative in a way that *helps fixing* the bug. I'm sure that there somewhere among the 319 above comments really are such constructive comments hidden, but who are able to find them today? I don't wan't to read through all these comments to find the interesting ones, and I'm sure the developers don't want to do that either. Actually this is a spam-comment to I'm writing, doing nothing constructive to help fixing the bug. But I guess all active developers has stopped monitoring this bug a long time ago, because of all the junk/spam posted here. So I thought it problably didn't matter if I spammed a little too...

Hopefully the developers they found other ways to communicate about how best to fix this bug, and maybe it is good tactics to keep this bug open for comments of the more immature and less constructive kind.

Whats the purpose of this comment? Oh well, don't know. Just thought I should throw some mud too...

Seriously hope the developers ain't monitoring this bug any more, and if they are I deeply regret posting another spam...
My desire to fix this bug is less than my desire to not hear people justify why their reason for complaining is better the reasons given by the previous 300 people.
Assignee: cst → guifeatures
Status: ASSIGNED → NEW
QA Contact: tpreston
(In reply to comment #320)
> My desire to fix this bug is less than my desire to not hear people justify why
> their reason for complaining is better the reasons given by the previous 300
> people.

Please stop cluttering up this bug with complaints.
(In reply to comment #315)

> Yelling at concerned users is a great way to win converts to Firefox.

Haven't you ever read a bug report before?  

FIREFOX DEVELOPERS DON'T CARE IF ANYONE USES FIREFOX.  ALL THEY CARE ABOUT IS YOU NOT BUGSPAMMING THE COMMENTS OF THE BUGS THEY AREN'T GOING TO FIX ANYWAY.

(In reply to comment #318)

> 5) Pretty soon, no one will ever use FF again because of this bug.
> and
> 6) Pretty soon, no one will ever develop FF again because of the complaints
> about the bug on this forum.

Both the advocacy bugspammers and the anti-bugspam bugspammers are a problem.  Bugzilla either needs:

1. A way to hide useless comments (or parts of comments) like "this bug should really be fixed" or "stop cluttering up this bug with complaints".
2. A "talk page" for discussing the bugs without cluttering up the actual comments, like Wikipedia has.  I've seen people say "discuss the bug on Mozillazine; not here".  But that doesn't work, does it?

Even better, combine the two.  Each bug should have a separate page/section for discussion, and when people bugspam, the comments can be moved to the discussion area.

Then people can continue griping and commenting on the bugs they care about, the developers can continue aggressively ignoring comments and the unimportant people who make them, and the main bug area can be left alone for reports, ideas, progress, and solutions.
Perhaps at this point this bug should also be marked as dependant on Bug 225751
Blocks: tibco
Assignee: guifeatures → cst
Severity: major → enhancement
Summary: Long tooltips should wrap instead of being cropped (multiline tooltips) → SeaMonkey-only bug: Long tooltips should wrap instead of being cropped (multiline tooltips)
Whiteboard: DO NOT COMMENT! THIS IS NOT A FIREFOX BUG! [seamonkey. blocked by bug 228673.] → DO NOT COMMENT! THIS IS NOT A FIREFOX BUG!
Target Milestone: Future → seamonkey1.1beta
Fixed in bug 356900 for SeaMonkey.  Do not reopen this bug.  If I caused any regressions or there are cases where the patch doesn't work, reopen bug 356900.  If you don't like the behavior I implemented, file a followup bug (but do *NOT* cc me unless you've contributed at least 1 patch - if you haven't, I probably don't care what you think).  If you have something to say about Firefox, don't spam SeaMonkey bugs.
Status: NEW → RESOLVED
Closed: 21 years ago18 years ago
Resolution: --- → FIXED
(In reply to comment #322)
> Both the advocacy bugspammers and the anti-bugspam bugspammers are a problem. 
> Bugzilla either needs:
> 
> 1. A way to hide useless comments (or parts of comments) like "this bug should
> really be fixed" or "stop cluttering up this bug with complaints".
> 2. A "talk page" for discussing the bugs without cluttering up the actual
> comments, like Wikipedia has.  I've seen people say "discuss the bug on
> Mozillazine; not here".  But that doesn't work, does it?
> 
> Even better, combine the two.  Each bug should have a separate page/section for
> discussion, and when people bugspam, the comments can be moved to the
> discussion area.

It may amuse you to note that I filed a proposal along these lines against Bugzilla in 2001.  See bug 79534.  Of course, nothing has been done; there's the great comment, "This is a common request, and one that I'd honestly just like to WONTFIX."  Because that's clearly the right thing to do with a common request.

Feel free to vote for bug 79534, and add your suggestions.
this is the most awesomest bug report i've read this year.
I'm confused.  This started as a Firefox bug, but it has now been closed as a fixed Seamonkey bug.  But the problem still exists in Firefox.

Please could someone explain what is going on here?
There must be another bug for Firefox for this problem... I hope!
There is a firefox bug, you can find it in the earlier comments here. If you fee there are too many to look through, try not making more :)
As comment 95 and comment 300 state, bug 218223 is the relevant Firefox bug.  The problem does *not* exist in Firefox anymore.  It has been fixed on the trunk as of April 24, 2007, i.e., for nine months.  The fix will not be backported to Firefox 2, but will be present in Firefox 3, which is in public beta and will almost certainly be released this year.

This bug is verified fixed in all Mozilla products.  There is no reason to comment further.  If there are further issues, open a followup bug.  And given that people will still comment, I guess if you don't like the bugspam you can just un-vote for this, since it's already fixed anyway.
Not very thoughtful, Tuukka.  Not everyone understands the sophisticated environment in bugzilla.  I was trying to provide feedback to Julian, to the extent that I could.

Thank you for actual information, Simetrical.  I did look through the previous comments for a while before this, and did not see that information.  It seems a cross-reference to the Firefox bug should have been in this bug's header, such as in the whiteboard, and should not only be hidden in the comments area (this is certainly not a critique of commenters #95 and #300).
Component: XP Apps: GUI Features → UI Design
QA Contact: ui-design
Status: RESOLVED → VERIFIED
If you are still experiencing this bug in Firefox, and have upgraded to version 3+, try this:

Open about:config

Look for browser.chrome.toolbar_tips

Set the value to True.

Mine was false.  I changed it, and now everything works fine.
Keywords: helpwanted
I have a title attribute with a long text in it while the HTML element is truncated the tool-tip gets cut off. This happens only in Firefox 38
Flags: needinfo?(oghwieufuoma)
Flags: needinfo?(info)
You need to log in before you can comment on or make changes to this bug.