Last Comment Bug 218223 - Long tooltips should allow wrap to multiple lines
: Long tooltips should allow wrap to multiple lines
Status: VERIFIED FIXED
:
Product: Firefox
Classification: Client Software
Component: General (show other bugs)
: Trunk
: All All
: P2 normal with 77 votes (vote)
: Firefox 3 alpha4
Assigned To: :Gavin Sharp [email: gavin@gavinsharp.com]
:
Mentors:
: 222697 242605 263500 264862 280251 281966 292136 295031 300747 301781 302692 306085 306675 316513 336407 376822 380707 382148 385464 386034 395666 400376 (view as bug list)
Depends on: 378846 382937 404122
Blocks: 358452
  Show dependency treegraph
 
Reported: 2003-09-03 13:53 PDT by Ben Goodger (use ben at mozilla dot org for email)
Modified: 2011-09-25 17:57 PDT (History)
83 users (show)
mbeltzner: blocking‑firefox3+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
illustration of why tooltip should wrap (11.80 KB, image/png)
2004-12-01 13:28 PST, john
no flags Details
tooltip bug (37.16 KB, image/jpeg)
2005-02-16 20:15 PST, bryan yu
no flags Details
fix, with much debt to CTho's work in 356900 (2.79 KB, patch)
2007-02-02 13:18 PST, Mike Shaver (:shaver -- probably not reading bugmail closely)
no flags Details | Diff | Review
As above, but unified and such. (4.75 KB, patch)
2007-02-02 13:27 PST, Mike Shaver (:shaver -- probably not reading bugmail closely)
no flags Details | Diff | Review
example of long image mouseover text truncated by firefox (55.44 KB, image/jpeg)
2007-04-12 09:49 PDT, max hodges
no flags Details
patch with nits fixed and pinstripe changes (5.87 KB, patch)
2007-04-24 09:14 PDT, :Gavin Sharp [email: gavin@gavinsharp.com]
gavin.sharp: review+
Details | Diff | Review
long title overflows SM-window (63.78 KB, image/jpeg)
2007-04-25 03:27 PDT, tonda kavalec
no flags Details

Description Ben Goodger (use ben at mozilla dot org for email) 2003-09-03 13:53:52 PDT
Firebird version of bug 45375
Comment 1 Bill Mason 2003-10-17 16:21:44 PDT
*** Bug 222697 has been marked as a duplicate of this bug. ***
Comment 2 Bill Mason 2004-05-04 15:42:18 PDT
*** Bug 242605 has been marked as a duplicate of this bug. ***
Comment 3 Neill Dumont 2004-07-12 19:45:09 PDT
I use these tooltips a LOT and see no reason why they can't be corrected by
Firefox 1.0.  I thought Firefox was standards compliant?  Walk your talk.
Comment 4 Asa Dotzler [:asa] 2004-07-27 10:45:29 PDT
Neill Dumont, your comment does nothing to add to the value of this bug. Please
don't waste our time with useless advocacy comments or your account will be
disabled. 
Comment 5 Anko 2004-08-11 03:06:15 PDT
Does this bug depend on Bug 99457? Should I/someone add the dependancy?
Comment 6 Bill Mason 2004-10-08 09:49:09 PDT
*** Bug 263500 has been marked as a duplicate of this bug. ***
Comment 7 Bill Mason 2004-10-18 06:29:27 PDT
*** Bug 264862 has been marked as a duplicate of this bug. ***
Comment 8 john 2004-12-01 13:28:01 PST
Created attachment 167580 [details]
illustration of why tooltip should wrap

here is a site where the last crucial information from the tooltip is snipped
http://www.pp.co.nz/CPUs-AMD.php
Comment 9 Bill Mason 2004-12-01 13:56:41 PST
(In reply to comment #8)
> Created an attachment (id=167580)
> illustration of why tooltip should wrap
> 
> here is a site where the last crucial information from the tooltip is snipped
> http://www.pp.co.nz/CPUs-AMD.php

Please see comment 4 before making comments that do not contribute to the
resolution of the bug.
Comment 10 Pascal Chevrel:pascalc 2005-01-27 03:35:39 PST
dupe

*** This bug has been marked as a duplicate of 45375 ***
Comment 11 Dan 2005-01-27 06:55:40 PST
(In reply to comment #10)
> dupe
> 
> *** This bug has been marked as a duplicate of 45375 ***

Isn't this a firefox bug and Bug 45375 a Suite bug?

If so, I request this be re-opened.. if Bug 45375 applies to both FF and the
Suite then I request it is marked as such..

Thanks
Comment 12 Jo Hermans 2005-01-28 13:56:51 PST
*** Bug 280251 has been marked as a duplicate of this bug. ***
Comment 13 Phil Ringnalda (:philor) 2005-02-11 15:17:59 PST
*** Bug 281966 has been marked as a duplicate of this bug. ***
Comment 14 bryan yu 2005-02-16 20:15:57 PST
Created attachment 174546 [details]
tooltip bug

tooltip can't also handle new line
Comment 15 Unknown W. Brackets 2005-02-16 22:55:49 PST
(In reply to comment #14)
> Created an attachment (id=174546) [edit]
> tooltip bug
> 
> tooltip can't also handle new line

Yes, indeed that is what this bug is about and what many of the proposed patches
have been meant to do.  Please, we are not blind; I don't think this bug needs
any more screenshots.

To anyone who has the power: can this bug be, perhaps, renamed to "Tooltips
should wrap and show multiple lines" or some other more verbose description like
the Mozilla equivalent has?

Thanks,
-[Unknown]
Comment 16 jeff forssell 2005-02-16 23:41:15 PST
> To anyone who has the power: can this bug be, perhaps, renamed to "Tooltips
> should wrap and show multiple lines" 
I support that suggestion /jeff
Comment 17 Jon Dowland 2005-02-17 01:39:27 PST
Sorry to be a pest, but I don't :) I'm in favour and support the idea of
tool-tip text being managed sensible (i.e. wrapped) so that it is visible but I
am not in favour of newlines in the attribute being interpreted as breaks. We
don't do this for CDATA (e.g. you need explicit BRs, or Ps) so it shouldn't be
done for attributes, IMHO.

I guess at the core there are two bugs.
Comment 18 jeff forssell 2005-02-17 01:51:15 PST
(In reply to comment #17)
> Sorry to be a pest, but I don't :) I'm in favour and support the idea of
> tool-tip text being managed sensible (i.e. wrapped) so that it is visible but I
> am not in favour of newlines in the attribute being interpreted as breaks. We
> don't do this for CDATA (e.g. you need explicit BRs, or Ps) so it shouldn't be
> done for attributes, IMHO.
> 
> I guess at the core there are two bugs.

I find the implementation which also allows linebreaks to be show as if <pre>
but would like it even better if it were to be able to be formatted with BR P
(even others like STRONG EM ...) 

There are sites that discovered that formating with simple linebreaks could make
the information clearer.  I can't see any reason to not support increased
clarity. Though I would even support having tags in title be evaluated (tho I
suspect that "hardcore" "specificationalists" would have an even harder time 
with that)

I want to be able to honestly say that FF is better that IE even in this case.
(which it isn't right now) /Jeff
Comment 19 Jon Dowland 2005-02-17 03:58:48 PST
(In reply to comment #18)

> There are sites that discovered that formating with simple linebreaks could
> make the information clearer.  I can't see any reason to not support
> increased clarity.

I find that sites which have enough information in the attributes so that
formatting like this becomes necessary should really put the information
elsewhere. Bear in mind that pop-ups are not available in all browsers, do not
show up when printed, etc.

> Though I would even support having tags in title be evaluated (tho I suspect
> that "hardcore" "specificationalists" would have an even harder time with
> that)

XML attributes cannot contain < > or &
Comment 20 jeff forssell 2005-02-17 04:31:45 PST
> I find that sites which have enough information in the attributes so that
> formatting like this becomes necessary should really put the information
> elsewhere.


"necessary" is a dangerous word like "obvious" "should" which always must be
related to a defined goal to have real meaning. 

My most common use for the title attr is in marking links. Goal: To help the
person that is about to click be extra sure that that link will take him where
he wants to go or not, or maybe warn him about some detail he should know.

I find myself often in conflict with the "clean" page people that want to have
"the ten commandments" with only the "necessary" 6 best ones because "people
can't read things on the internet as though they were printed"  

I feel like a good title attr is a nice way to hit a middle ground with a
relatively clean page that stills gives relevant extra info for a link or button
choice.

And I still want FF to be better than IE even in this case. At least give the
user chance to chose which rendering he/she wants.  (Why would anyone want to
NOT see the way a person, that obviously and consciously tried (often in spite
of sticky fingered editors that rearrange code), has written the title attr? Oh
well, there might be some.)  

>XML attributes cannot contain < > or &
I guess XML does not forbid line breaks in the code(or you would have mentionsed
that), which would in that case make it possible for FF to render them. That
sounds promising.
Comment 21 Matthew Austin 2005-02-17 13:06:00 PST
> I find that sites which have enough information in the attributes so that
> formatting like this becomes necessary should really put the information
> elsewhere. Bear in mind that pop-ups are not available in all browsers, do not
> show up when printed, etc.

There are times when it's necessary to put a flood of information in title tags,
such as on an online user manual or training graphic rollovers (which was what
my original complaint had to do with in the first place).

It's frustrating for a few reasons:
(1) There are sometimes tooltips in other places that are longer than 80
characters, esp. links and the like (though Firefox does not touch such things
in the same nature that Aiiiiieeeeee does unless the <a> tag has some sort of
special title attribute, and even then...).
(2) I don't mean to sound crass, but if IE can do it, why can't Firefox? 
(Please do not kill me...) Firefox has kicked IE's *ahem* up and down the
markets, what with 25 million downloads in four months and it has features that
IE will probably never have, but it can't handle title tags properly...

Is there anything I can do to help here?
Comment 22 R.K.Aa. 2005-03-21 12:22:17 PST
*** Bug 287094 has been marked as a duplicate of this bug. ***
Comment 23 Hans Prueller 2005-04-07 02:45:36 PDT
That's also my opinion. It is a fact that there ARE REASONS why the title
attribute is longer than 80 characters and should be wrapped instead of cut off.

I am currently writing a business application that is displaying a mass of
geographic points on a map by using html layers. there are about 200 or more
points on the map to be displayed at once (e.g. movement history). If the user
wants to have more detailed information on a special point like time, speed or
other information he just has to move the mouse over the point to see the
content of the title attribute. this works fine in IE but a firefox user won't
see all information he needs. I don't think that there would be a more practical
solution available than to use the title-attribute for this reason.

hans
Comment 24 Matthias Versen [:Matti] 2005-04-27 16:29:51 PDT
*** Bug 292136 has been marked as a duplicate of this bug. ***
Comment 25 Matthias Versen [:Matti] 2005-05-21 07:54:07 PDT
*** Bug 295031 has been marked as a duplicate of this bug. ***
Comment 26 Erik Fabert 2005-07-14 03:32:46 PDT
*** Bug 300747 has been marked as a duplicate of this bug. ***
Comment 27 Erik Fabert 2005-07-23 01:36:16 PDT
*** Bug 301781 has been marked as a duplicate of this bug. ***
Comment 28 Phil Ringnalda (:philor) 2005-07-29 15:38:57 PDT
*** Bug 302692 has been marked as a duplicate of this bug. ***
Comment 29 Uri Bernstein (Google) 2005-08-26 13:05:34 PDT
*** Bug 306085 has been marked as a duplicate of this bug. ***
Comment 30 Jo Hermans 2005-09-01 02:45:22 PDT
*** Bug 306675 has been marked as a duplicate of this bug. ***
Comment 31 Erik Fabert 2005-11-15 08:12:00 PST
*** Bug 316513 has been marked as a duplicate of this bug. ***
Comment 32 Wayne Mery (:wsmwk, NI for questions) 2006-03-01 13:21:15 PST
shouldn't this bug depend on bug 228673 if it has the same problems as suite bug 45375?


(In reply to Bryan Yu comment #14)
> Created an attachment (id=174546) [edit]
> tooltip bug
> 
> tooltip can't also handle new line

that is Bug 67127

Comment 33 Steve England [:stevee] 2006-05-03 04:42:57 PDT
*** Bug 336407 has been marked as a duplicate of this bug. ***
Comment 34 Paolo Brocco 2006-05-06 08:42:45 PDT
My little contribution for web developers frustraded of this bug: you may find useful a javascript workaround such this one: (Bubble Tooltips) http://www.web-graphics.com/mtarchive/001717.php or this one: http://www.walterzorn.com/tooltip/tooltip_e.htm
Comment 35 theo 2006-05-25 16:09:19 PDT
The major news website slate.com has just launched a new "Documents" series which relies on long <TITLE> tooltips.  At present, it's unusable with Firefox.

Example: http://www.slate.com/id/2142381

I've contacted them, but I don't really expect a fix (although Slate is no longer owned by Microsoft).
Comment 36 KLB 2006-09-24 22:30:29 PDT
I'm following up on this bug, which from the surface seems to be the same issue being discussed in bug 45375 for SeaMonkey but is really a core Gecko issue. It seems that this bug has been an issue for over six years, but is now becoming much more of an issue as web developers are starting to use the TITLE attribute as it was intended by W3C specifications. For instance very common web applications like vBulletin now make use of the TITLE attribute quite heavily as do many other sites.  As a result this bug has become a major functionality issue that really needs it priority and severity raised so that it gets the attention it needs to get resolved. See bug 45375 for the long testimonials about the usability issues this bug is causing.

It seems kind of crazy that a bug of this nature has languished for six years.
Comment 37 Steuard Jensen 2006-10-20 13:52:31 PDT
There's been some recent activity related to this issue that I thought should be mentioned in this bug.  Specifically, bug 356900 was recently filed and fixed: from the sound of it, the patch there essentially fixes bug 45375 (the SeaMonkey version of this bug) and bug 67127 (whose focus for years has been trying to allow explicit line breaks in tooltips; it was just recently relabeled as a SeaMonkey-only bug, though I'm not quite sure why).  There may be difficulties that I'm not expert enough to recognize, but it's possible that this SeaMonkey patch could be adapted to fix the same two issues for Firefox.

The most important caveat that I can see is the desired behavior of newline characters in tooltip text (yes, that's a bit off-topic for this bug, but important if anyone goes to implement this).  That issue was discussed thoroughly in bug 67127, and the best conclusion found was described in bug 67127 comment 131.  If a Firefox patch along the lines of the fix for bug 356900 is created, I would recommend that my interim patch for bug 67127 be left intact until bug 322270 is fixed (which will deal with whitespace in attribute values more generally).
Comment 38 Dricks 2006-11-30 06:12:30 PST
Ok, this problem is there since 2004-12-01

2 years and XXXXX releases later, this is still unfixed.
Damn, is there any gecko's developer around here, or is it a faked bugzilla?

Is it normal to still have ugly tooltip behaviors in this software?
Is it planned to be fixed in something less than 10years (as the target milestone for this bug is marked as 'FUTURE' which means 'never, but we don't want to say it'. )
Comment 39 Ria Klaassen (not reading all bugmail) 2006-12-23 14:31:22 PST
Some sites are based on tooltips and you can use these sites with Firefox.
Like this site: http://www.hair-science.com/_int/_en/topic/topic_sousrub.aspx?tc=ROOT-HAIR-SCIENCE^PORTRAIT-OF-AN-UNKNOWN-ELEMENT^SUPERB-CHEMISTRY&cur=SUPERB-CHEMISTRY
Hover over "amino acids" or "hydrogen bonds".
Comment 40 Dricks 2007-01-12 05:38:15 PST
Couldn't Mozilla's fondation use some of their 44,7 millions dollars $$$ benefits to correct this bug?
Comment 41 David Hammond 2007-01-12 06:05:01 PST
Money doesn't equal ability to get work done. Just look at IE. If you want this to be fixed, just vote for it and stop the comment spam. This is a high priority issue for me too, but begging here is only going to annoy the people who are already watching the issue.
Comment 42 Mike Shaver (:shaver -- probably not reading bugmail closely) 2007-02-02 13:18:54 PST
Created attachment 253778 [details] [diff] [review]
fix, with much debt to CTho's work in 356900

This was motivated by the arrival of my copies of Lockpick Pornography and Truth and Beauty Bombs, which reminded me of Ryan North asking so nicely for this fix at a dinner last year.  Probably branch-worthy after some trunk baking, but possibly incompatible with extensions which assume that tooltip has no children, so we'd have to hold off for a 2.0.1.x.

This fails the second test on http://www.webdevout.net/testcases/title_tooltips/ (no line break), in exchange for passing test 3 (not looking like total crap).  We can reverse that decision by removing the newline stripping line (see the comments also for why we have to make that choice).

I am violently, vehemently not [ ] taking this bug.
Comment 43 Mike Shaver (:shaver -- probably not reading bugmail closely) 2007-02-02 13:27:47 PST
Created attachment 253782 [details] [diff] [review]
As above, but unified and such.

Whoops.
Comment 44 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-02-19 09:38:52 PST
(In reply to comment #42)
> This fails the second test on
> http://www.webdevout.net/testcases/title_tooltips/ (no line break), in
> exchange for passing test 3 (not looking like total crap).  We can reverse
> that decision by removing the newline stripping line (see the comments also
> for why we have to make that choice).

As I understand it, SeaMonkey chose the non-stripping behavior to allow authors to add explicit newlines, and because it matches IE behavior. Are we not better off to do the same, for the same reasons? I suppose that means a change in behavior when bug 322270 is fixed, if it is. At the very least, if we go with this approach, the XXX comment should mention bug 322270.
Comment 45 Mike Shaver (:shaver -- probably not reading bugmail closely) 2007-02-19 10:49:18 PST
I have no objection to following that path.  I probably won't get to it until the weekend -- do you want to do that as a follow-up patch, or do you think we'll be making things worse by putting this in as-is?
Comment 46 Steuard Jensen 2007-03-16 18:51:11 PDT
I would strongly object to implementing the IE behavior here.  Part of that is selfish: my motivation for fixing bug 67127 was to eliminate the bizarre tooltip problems I encountered just because I word-wrapped my HTML (which should have no effect, according to the HTML spec).  Switching to the IE behavior would re-break Firefox's tooltips, and would require some sort of further fix in the future.  (And a future fix /is/ important: bug 322270 affects much more than just tooltips.)  Personally, I'm much more interested in keeping whitespace handling remotely sensible than I am in the ability to add line breaks to my tooltips.

I think that it would invite many intense complaints if Firefox briefly supported IE's incorrect behavior here and then later removed that support.  (To many users, it would seem like we had endorsed a de-facto standard and then abandoned it.)  As I see it, it would be much more reasonable to hold off on allowing author-specified newlines in tooltips until we can tell the web developer community "Here's a /good/ (and standards compliant) way to implement this."  We could try to tell people to use &#13; rather than just hitting enter to be ready for the future fix, but I doubt that many would do so as long as they act the same way.


Getting back to this patch as written, a quick note on the HTML spec itself (as implemented in the current patch here): I've always been bothered by the difference in handling of CR and LF in the specification, because it means that identical-looking code written on different platforms may render differently.  I don't know what to do about that (apart from hoping that a future version of the standard fixes the problem), but it's why I went somewhat non-standard in my earlier fix to bug 67127.  Meanwhile, I don't think that the spec says anything about whether or not the /rendering/ of a tooltip should collapse whitespace or not; my philosophy is that if we do it for plain text by default in HTML and CSS, why shouldn't we do it for tooltips?  I've discussed this in some depth at bug 356900.
Comment 47 David Hammond 2007-03-17 08:17:46 PDT
In theory, I would assume that any displayed version of the title attribute (such as in a tooltip) should be derived from the attribute value as it exists in the DOM. The value in the DOM should have the whitespace collapsed like normal. Therefore, the displayed tooltip shouldn't be retaining any newlines or sequences of whitespace from the raw source.

Character references are a different issue, since (I believe) they are supposed to be translated after the initial whitespace collapsing, and therefore the characters referenced don't collapse like normal whitespace.

I agree with Steuard; adding new incorrect behavior isn't the way to go.
Comment 48 Duncan Loveday 2007-03-25 08:46:01 PDT
FWIW I've added my vote to this bug, however I agree with the sentiment that whilst wrapping long lines to make them visible ought to be done, explicit line breaks and other types of formatting should not be done unless there is a standards compliant way to go.
Comment 49 Sergey «Mithgol the Webmaster» Sokoloff 2007-03-27 11:23:44 PDT
The patch (as it is at https://bugzilla.mozilla.org/attachment.cgi?id=253782 right now) applies

   t = t.replace(/[\r\t]/g, ' ');

and

   t = t.replace(/\n/g, '');

I beg your pardon, why the empty string in the latter?
What if t == 'multiple\nwords'?

Also, the 'white-space: -moz-pre-wrap;' is going to preserve subsequent white spaces instead of collapsing (folding) them together, isn't it?

Then t.replace(/\s+/g, " ") is probably necessary unless you're going to become too MSIE-compatible. This bug is about wrapping to multiple lines; collapsing or not collapsing white spaces in tooltips is probably a different and independent issue.
Comment 50 Steuard Jensen 2007-03-27 13:07:32 PDT
The different treatment of \r and \n in the current patch follows directly from the HTML spec (in the section referenced in the patch), which (as I noted at the end of comment 46) I find less than pleasant: that's why I broke slightly from the standard with my "s/\s+/ /g" replacement.  I'd love to understand why the spec reads as it does here.

Meanwhile, yes, the right place to discuss policy on author-specified line breaks (and related whitespace issues, I'd think) is probably bug 358452 (Firefox) or bug 67127 (SeaMonkey, but originally more general).  I'd rather see this bug (and any patches to it) focus on the automatic wrapping issue.

Oh, and as a side note, my understanding from bug 357337 is that CTho's SeaMonkey patch in bug 356900 actually breaks when incorporated with the reflow branch (my impression was that the solution on the reflow branch would actually be much simpler, but I won't swear to that).  Has the current patch here been tested on both 1.8 and 1.9?
Comment 51 Mike Shaver (:shaver -- probably not reading bugmail closely) 2007-03-27 17:01:45 PDT
(In reply to comment #49)
> The patch (as it is at https://bugzilla.mozilla.org/attachment.cgi?id=253782
> right now) applies
> 
>    t = t.replace(/[\r\t]/g, ' ');
> 
> and
> 
>    t = t.replace(/\n/g, '');
> 
> I beg your pardon, why the empty string in the latter?

Because, in the section of the HTML specification that I explicit mention in the patch you link to, that's what it says to do with newline characters, no?  That was my reading of it, but if I made a mistake in my interpretation I'm more than open to correction.
Comment 52 Gábor Stefanik 2007-04-03 12:43:45 PDT
->alpha4. Alpha3 is gone.
Comment 53 Phil Ringnalda (:philor) 2007-04-09 18:14:25 PDT
*** Bug 376822 has been marked as a duplicate of this bug. ***
Comment 54 max hodges 2007-04-12 09:37:55 PDT
not to be a pest but this bug was reported 4 years ago. it's upsetting that had to user FIND on the html source code in order to read some image title text on sites like xkcd which makes frequent use of long mouseover image text. How much money do you guys need to fix this? I can start a collection plate, just put a price tag on it.

Best Regards
Comment 55 max hodges 2007-04-12 09:49:47 PDT
Created attachment 261394 [details]
example of long image mouseover text truncated by firefox

In Firefox I need to view source and use Find to search for a tooltip keyword in the source text in order to read the complete tooltip text. Internet Explorer handles it beautifully.
Comment 56 Edgaras 2007-04-12 10:09:58 PDT
Why search source if you can view title in Properties
Comment 57 Timwi 2007-04-12 10:28:54 PDT
> How much money do you guys need to fix this?

I think the general reply to this would be, "We don't need money, we need a developer to do it."

> Why search source if you can view title in Properties

I didn't think of that. It is quite unobvious.
Comment 58 Mike Shaver (:shaver -- probably not reading bugmail closely) 2007-04-12 10:43:30 PDT
There's a patch to fix this issue here in this bug, and if you had bothered to read the bug before commenting on it you would have seen both the patch and the discussion.  Neither advocacy comments nor additional test cases are helpful at this point, unless the test cases vary incorrectly in behaviour after the patch is applied.  Please do not comment on this bug unless you are providing specific feedback on the patch or the plan described for fixing it.  Thank you.
Comment 59 Jon B 2007-04-12 11:04:30 PDT
(In reply to comment #58)
> Please do not comment on this bug unless you are providing
> specific feedback on the patch or the plan described for fixing it.

You're doing the exact same thing by responding to it.
Comment 60 spam 2007-04-12 11:16:13 PDT
So are you.(In reply to comment #59)
> (In reply to comment #58)
> > Please do not comment on this bug unless you are providing
> > specific feedback on the patch or the plan described for fixing it.
> 
> You're doing the exact same thing by responding to it.
> 

So are you =)
Comment 61 Mike Shaver (:shaver -- probably not reading bugmail closely) 2007-04-12 11:36:21 PDT
(In reply to comment #59)
> (In reply to comment #58)
> > Please do not comment on this bug unless you are providing
> > specific feedback on the patch or the plan described for fixing it.
> 
> You're doing the exact same thing by responding to it.

I wrote the bloody patch, and am following the bug for review feedback and to get it in the tree, so I'm telling people to keep the noise down so that the bug stays useful.  I won't really be upset about disabling people's accounts if they aren't contributing productively.
Comment 62 Jon B 2007-04-12 16:21:35 PDT
(In reply to comment #60)
> So are you =)

Yep.

(In reply to comment #61)
> so I'm telling people to keep the noise down so that the
> bug stays useful.

"Don't post advocacy" comments have already been made a million times on this page.  If you want to scold those who continue to do it, reply to their email directly so it isn't cluttering up the bug for the rest of us.

I would be replying privately right now, except I want to draw attention to a proposed solution:

https://bugzilla.mozilla.org/show_bug.cgi?id=377311
Comment 63 Reed Loden [:reed] (use needinfo?) 2007-04-12 16:53:02 PDT
(In reply to comment #62)
> I would be replying privately right now, except I want to draw attention to a
> proposed solution:

If you reply privately, you will be in violation of the Bugzilla Etiquette (section 1, paragraph 4):
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Please take it to heart. :)
Comment 64 Michael Moulton 2007-04-12 17:23:01 PDT
That etiquette policy explicitly states "please place all information relating to bugs in the bug itself. Do not send them by private email."  Asking people to keep the advocacy comments out of the bug is not information relating to the bug, so it seems to me it would be appropriate to send privately.
Comment 65 max hodges 2007-04-12 21:53:39 PDT
> I find that sites which have enough information in the attributes so that
> formatting like this becomes necessary should really put the information
> elsewhere. Bear in mind that pop-ups are not available in all browsers, do not
> show up when printed, etc.
>
Yes, but in the cases where they exist, shouldn't we be able to read them? IE seems to handle these cases fine. Why is this just a problem for FF to address? it's been an issue for several years.

XKCD.com chooses to embeded verbose in these tags as a sort of hidden message for insiders. But one can imagine a site where the pages are generated programmatically and some description text is inserted into these tags automatically. Should we lobby w3c to put a clause in the HTML spec to limit text in these tags to 80 characters? or should we just wrap lines so that people can read the text when it appears in the tool-tip? This seems the obvious solution, and the solution implemented in IE.
Comment 66 max hodges 2007-04-12 22:01:51 PDT
>>Please do not comment on this bug unless you are providing
specific feedback on the patch or the plan described for fixing it.

Sorry, I'm new here and still learning my way around. Not really sure what blocking/wanting flags are and all that. I only noticed that it was reported in 2003 and the STATUS is still ASSIGNED to this day. No more advocacy comments from me.
Comment 67 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-04-24 09:14:47 PDT
Created attachment 262651 [details] [diff] [review]
patch with nits fixed and pinstripe changes

There are a couple of remaining minor issues (unnecessary wrapping in some cases), which as far as I can tell are due to bug 228673 and bug 357337. There is also the outstanding issue of whether we want to do the whitespace stripping or not, but I don't want to let that block progress here, so I'm going to land this patch and file a follow up on determining the exact behavior we want to ship with.
Comment 68 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-04-24 09:57:17 PDT
mozilla/browser/base/content/browser.css 	1.24
mozilla/browser/base/content/browser.js 	1.778
mozilla/browser/base/content/browser.xul 	1.341
mozilla/browser/themes/pinstripe/browser/browser.css 	1.45
mozilla/browser/themes/winstripe/browser/browser.css 	1.58

This bug is now FIXED on the trunk. Filed bug 378620 to make a decision about the whitespace stripping before the release.
Comment 69 tonda kavalec 2007-04-25 03:27:22 PDT
Created attachment 262746 [details]
long title overflows SM-window

Just a screenshot. The tooltip should may be resize himself relatively to window-size.

*[title] {
white-space: pre;
}

Is a great idea.
Comment 70 tonda kavalec 2007-04-25 03:32:13 PDT
Sorry I have meant its good, that the title-atribut-value is formated as predefined text.
Comment 71 Modex 2007-04-25 09:23:18 PDT
At this page http://forum.mozilla-russia.org/viewtopic.php?pid=177188#p177188 are two icons (UA of browsers)... Hover it... Tooltip small for first and big for second...

Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9a4pre) Gecko/20070425 Minefield/3.0a4pre
Comment 72 Jens Bannmann 2007-04-25 12:26:47 PDT
(In reply to comment #69)
> The tooltip should may be resize himself relatively to window-size.

I would say it shouldn't. Other Windows applications (Windows Explorer, Microsoft Word...) also display overlapping tooltips, e.g. when you hover a toolbar button that is near the window border.
Comment 73 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-04-25 14:51:25 PDT
(In reply to comment #71)
> At this page http://forum.mozilla-russia.org/viewtopic.php?pid=177188#p177188
> are two icons (UA of browsers)... Hover it... Tooltip small for first and big
> for second...

I don't see that problem, using a Mac trunk build. Could you file a bug on it, and CC me?
Comment 74 Modex 2007-04-26 07:05:46 PDT
(In reply to comment #73)
> (In reply to comment #71)
> > At this page http://forum.mozilla-russia.org/viewtopic.php?pid=177188#p177188
> > are two icons (UA of browsers)... Hover it... Tooltip small for first and big
> > for second...
> 
> I don't see that problem, using a Mac trunk build. Could you file a bug on it,
> and CC me?
> 

Filed Bug 378846
Comment 75 Phil Ringnalda (:philor) 2007-05-15 00:29:51 PDT
*** Bug 380707 has been marked as a duplicate of this bug. ***
Comment 76 [:Aleksej] 2007-05-26 23:34:57 PDT
*** Bug 382148 has been marked as a duplicate of this bug. ***
Comment 77 Jesse Ruderman 2007-06-22 10:07:06 PDT
*** Bug 385464 has been marked as a duplicate of this bug. ***
Comment 78 Dave Townsend [:mossop] 2007-06-27 04:10:12 PDT
*** Bug 386034 has been marked as a duplicate of this bug. ***
Comment 79 Angus McInnes 2007-06-27 04:21:55 PDT
Should there be an update to Firefox 2 to fix this? The bug has been fixed (i.e the code has been written), so I don't see why it should take another 6 months for a minor change like this to get into a stable version that people will actually use.
Comment 80 Timwi 2007-06-27 05:25:38 PDT
> Should there be an update to Firefox 2 to fix this?

I agree that there should -- but there won't be. Unless it's deemed a "security vulnerability", you won't see the fix until the next major release. Unless of course you use the "nightly builds", which contain the fix -- but also an assortment of half-baked unfinished features with new bugs that crash your system and lose your data.

This is frustrating and unsatisfactory, but it is widely considered a necessary evil in software engineering. IE and Opera are no better in this regard, and they don't give you the option of using the nightly builds.
Comment 81 Ryan VanderMeulen [:RyanVM] 2007-06-27 05:38:58 PDT
I'm not completely positive, but I'm quite sure that the (simple) fix from this bug depends on some much larger fixes in other bugs in order for it to function properly (aka, the Reflow Branch), hence why it can't be easily backported to Fx2.
Comment 82 Dave Townsend [:mossop] 2007-09-10 06:53:12 PDT
*** Bug 395666 has been marked as a duplicate of this bug. ***
Comment 83 Jesse Ruderman 2007-10-19 13:28:23 PDT
*** Bug 400376 has been marked as a duplicate of this bug. ***
Comment 84 Carsten Book [:Tomcat] 2008-01-08 06:28:17 PST
Verified fixed using Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9b3pre) Gecko/2008010705 Minefield/3.0b3pre ID:2008010705 and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b3pre)Gecko/2008010801 Minefield/3.0b3pre

-> Verified fixed 

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