HTML link "tooltips" (A element's title attribute) with newlines in them render incorrectly

no black square on linux build 2001-01-29-08. Could this be windows-only?

I am seeing this again with today's builds, both on my NT4 workstation and my
W2k laptop. Build 2001-01-31-09-Mtrunk/mozilla-win32-installer.exe

Confirmed
Platform: PC
OS: Windows 98
Mozilla Build: 2001012904

Marking NEW.

cc ian

Triaging karnaze's bugs.

This happens not only with ALT of images. Newline in anchor's TITLE also has small
ugly characters. I'll attach screenshot.

Created attachment 33161
Newline in title of anchor renders as black squares on WinME

See also bug 47078, Newlines are not converted to whitespace in attributes.

I'm going to dupe this into bug 47078. Both in HTML and XML, we should *never*
leave newlines in attributes; they should *always* be caught and turned into
whitespace at the parser.

*** This bug has been marked as a duplicate of 47078 ***

Reopening, this bug is still valid for quirks mode.

*** Bug 98120 has been marked as a duplicate of this bug. ***

Changing summary to accomodate duped bug (same underlying problem)

This is also highly visible at http://www.w3.org/TR/xhtml1/

............................

<h2 class="notoc">Abstract</h2>

<p>This specification defines <abbr title="Extensible Hypertext Markup
Language">XHTML</abbr> 1.0, a reformulation of HTML&nbsp;4
as an XML 1.0 application, and three <abbr title="Document Type
Definition">DTDs</abbr>

*** Bug 101151 has been marked as a duplicate of this bug. ***

This also happens on build 2001092205 Mac OS X 10.0.4 in title attributes in <a>
elements. Sorry about filing the duplicate.

*** Bug 49614 has been marked as a duplicate of this bug. ***

Created attachment 50434
Testcase with character entities for CR-LF

Should this be in Layout or XPApps? It needs to be fixed before we can do
proper whitespace handling (which, when implemented, will strip all linefeeds
that are *not* character entities); nominating for mozilla 1.0.

Reassigning to XPTOOLKIT

*** Bug 113796 has been marked as a duplicate of this bug. ***

*** Bug 119913 has been marked as a duplicate of this bug. ***

*** Bug 122109 has been marked as a duplicate of this bug. ***

*** Bug 122210 has been marked as a duplicate of this bug. ***

*** Bug 132252 has been marked as a duplicate of this bug. ***

*** Bug 140685 has been marked as a duplicate of this bug. ***

*** Bug 144068 has been marked as a duplicate of this bug. ***

*** Bug 144798 has been marked as a duplicate of this bug. ***

*** Bug 152243 has been marked as a duplicate of this bug. ***

*** Bug 154160 has been marked as a duplicate of this bug. ***

*** Bug 156133 has been marked as a duplicate of this bug. ***

It's because our nsTextBoxFrame doesn't support multi-line text.

so is there already someone creating another
nsTextBoxFrame that supports multi-line text? :)

yes, it's me :)

Created attachment 91779
let text frame be able to handle multi-line text

CCing alecf, jag, dean to review my patch.

Erh, this doesn't seem like the right solution to me.

Should we be making these multi-line or just converting the linefeeds to spaces?
 From bug 152243 comment 1:

'According to HTML 4.01, "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."'

Reply to comment #37:
As user I'm prefering multiline - with converting the linefeeds to spaces will
be very long text unreadable in one single line. Futhermore - it's very easy to
write text, which will be wider than any viewport.

I would choose to convert linefeeds to single spaces beacause there is one
more side effect. Sample code

<input type="text" value="Line breaks
here so you will see only one line">

When you place something like that in a page, input will show only "Line breaks"
but input also contains the rest -> so the user may submit not what he thinks.
Take a look at http://www.netpr.pl - there is a login form, on the right side
with such input - user sees only "twój" but input contains "twój login". So
people have problems with logging in.

Tooltips has anything to do with values of form widgets???

what do the tooltips for personal toolbar bookmarks use?

They show two lines: bookmark title, then bookmark url.

Can that feature be applied to "title" tooltips, allowing multi-line tooltips?

Regarding the "replace with space" vs "render as newline" issue, I cast
my vote in the "replace with space, but allow tooltips to wrap to mulitple
lines" camp.

-matt

Why does web developer put linefeeds here? Is that just a typo? I don't think
so. Run the test case in IE, you can see a two lines tooltip was shown.

Reply to comment #41:
The tooltip for personal toolbar is a two-lines textbox, because we can't get
tooltiptext="Google\n\rhttp://www.google.com" work :(

http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/navigator.xul#285

285 <tooltip id="ptTooltip" noautohide="true" onpopupshowing="return
FillInPTTooltip(document.tooltipNode)">
286 <vbox id="ptTooltipTextBox" flex="1">
287 <label id="ptTitleText" />
288 <label id="ptUrlText" />
289 </vbox>
290 </tooltip>

That's what we do for tooltips on bookmarks in the personal toolbar. I'm not
sure we can reuse that for title attributes on html elements, but then again I
think we should follow the html 4.01 spec and ignore linefeeds and replace
carriage returns with a space. Optionally we might choose to wrap long texts
instead of cropping them like we do now, though I think title is intended to be
a short description, not a screen filling document. Cropping will encourage the
former.

Kyle: I think you're right that some HTML developers have discovered this
bug/feature in IE and are taking advantage of it, but I strongly suspect that
there are plenty of pages where the developer hard-wraps the text (by pressing
enter) so it fits nicely on his screen and assumes the standard HTML behaviour
to apply.

I'm definately for multi-line support in the attribute.
Firstly, cause it's the way IE does it.
Secondly, cause I'm using that very same feature in my website (which will not
work if the browser would ignore linebreaks).

We already crop lengthy titles. Try this:

<a href="www.mozilla.org" title="this is a really really really really really
really really really really really really really really really really really
really really really really really really really really really really really
really really really really really really really really really really really
really really long title">mozilla.org</a>

See for example comment 13. I strongly doubt the W3 people intended "Extensible
Hypertext Markup Language" to be a two-line tooltip with just "Language"
appearing on the second line.

Jaak: it's cool that your site does what you want it to do in IE, I don't think
that's enough of a reason for us to break other sites.

Dean: I thought we did, thanks for confirming it.

Multi-line tooltips are extremely useful for creating an online application that
needs some short online help.

i.e.
--
Press this button to submit your changes.
Please make sure that you have entered your e-mail address correctly.
--

I think we need some way to break tooltips into multiple lines.

Reply comment 37:
I doubt where is the spec for that converting. I only see those 3 items at
http://www.w3.org/TR/html401/types.html#h-6.2 that is for CDATA. And this link
is for title attribute: http://www.w3.org/TR/html401/struct/global.html#h-7.4.3
Does it said we must convert linefeeds?

Some way, maybe. Something as ambiguous (within the context of html at least) as
a newline, no. Perhaps "line 1\nline 2" as suggested by Kyle earlier. From a
technical point of view, I don't think we should build multiline support into
nsTextBoxFrame, we already have a frame that deals with wrapping text, I think
we should re-use that instead.

sure, no probs, it is a minor feature anyway.

just have to wait until all people are designing websites for IE (:o),
so the multi-lined hints in Mozilla could be turned on,
without breaking any websites ;)

Kyle:
http://www.w3.org/TR/html401/struct/global.html#adef-title
says that title is of type text.

http://www.w3.org/TR/html401/types.html#type-text
says that text is %Text; in the DTD

http://www.w3.org/TR/html401/sgml/dtd.html#Text
says that %Text; is CDATA.

So yeah, it does say that.

"Multi-line tooltips are extremely useful for creating an online application that
needs some short online help.

i.e.
--
Press this button to submit your changes.
Please make sure that you have entered your e-mail address correctly."

You shouldn't rely on tooltips to convey so much information. If it's not
obvious from your form what something does, the form should have the help text
directly on it.

I saw that. jag and dean, you are right.

"You shouldn't rely on tooltips to convey so much information. If it's not
obvious from your form what something does, the form should have the help text
directly on it."

It was just an example. I use tooltips on my personal webpage in a table if
recent visitors. It's just a small table so I cut off the text of the IP
address/hostname if it's too long. Hover the mouse over it and the full name
gets displayed along with the referrer (referrer on a separate line). Displaying
the information every time would hog up way too space, and clicking on a link to
go somewhere else to display those two lines would be overkill. The tooltip
however, works great for this.

I'm just saying that tooltips should have multiple lines. If the title tag won't
support it then there should be an alternate way of doing it. Unless you can
think of a reason tooltips ought not be able to have multiple lines?

"Unless you can think of a reason tooltips ought not be able to have multiple
lines?"

The standard says they shouldn't. See comment 48 and 51. Important quotes from
the first link in comment 48 is "Ignore line feeds" and "Replace each carriage
return or tab with a single space".

For an example, i want to use title for IMG object. In the title there will be
text like this:

"
Name: IMG_NAME.jpg
Date: 2002-07-18
Scene: World Cup match Poland-Brasil
Access: xrwr-r-
Author: Jon Smith
"

It'd be very usefull for me in this and many other situation. Tooltip is very,
very helpfull in interface. It doesn't grab space, its easy to implement... Why not?

nominating for nsbeta1, because there are 14 duplicates and so many complains.

We must do something for this, either fix it or mark won't fix :(

I've sent e-mail to Hixie and dbaron about interpretation of the spec and/or
compatibility support.

WONTFIX is not the right solution here, there are still black boxes which we
shouldn't display. So either this is a dupe of bug 47078 or we need to add
support for multiline tooltips (easiest should be to change the tooltip binding
to use <xul:html/> instead), which means that when bug 47078 is fixed we'll need
to make sure we can somehow get the unchanged data.

=> component owner

I'm all in favor of doing the right (read: standards-compliant) thing and duping
this against 47078.

*** Bug 172534 has been marked as a duplicate of this bug. ***

Ack. I should have cc'd myself to this bug a while ago. There's a fundamental
confusion here as to what this bug is about:
1) HTML 4.01 requiring newlines to be converted to whitespace in attributes (bug
470478). This is a valid bug, BUT it only applies to newlines present as such in
the source. If you place the entities &#10;&#13; in the text of a title
attribute, this SHOULD produce a linebreak. This is the ONLY way to produce a
linebreak in attribute text. So I would advise changing the binding and allowing
multi-line tooltips as standards-correct. (We could still decide not to respect
line breaks when they appear within a tooltip box, just as we don't let them
break text in an HTML page except in <pre>, but that would be an internal
decision regarding tooltip rendering and have nothing to do with the HTML 4.01
spec.)

I totally agree with Chris. See comment 37, "Replace each carriage return or tab
with a single space.", What does this mean? IMO, It means that we should convert
the "invisible* carriage return/tab to a single space, like this:
"fooA fooB
fooC fooD" =>
"fooA fooB fooC fooD"
But for the soft coded |\n\r|, it should be kept there to satisfy the
webdesigner's original intention.

*** Bug 173025 has been marked as a duplicate of this bug. ***

*** Bug 178942 has been marked as a duplicate of this bug. ***

nsbeta1+/adt3 per the nav triage team.

*** Bug 180279 has been marked as a duplicate of this bug. ***

*** Bug 182471 has been marked as a duplicate of this bug. ***

*** Bug 111609 has been marked as a duplicate of this bug. ***

*** Bug 184700 has been marked as a duplicate of this bug. ***

Created attachment 109093
testcase - view with IE and Mozilla

I read this entire bug, and I disagree with people who says tooltips shouldn't
have newlines because the standard explicitly says that character entries
should be translated as I mentioned in comment 211 of bug 25537. There are
character entries for newlines, backspaces and tabs.

Now, I know you've heard the following before (just bear with me):

<!ENTITY % Text "CDATA">

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* [emphasis mine],
Ignore line feeds,
Replace each carriage return or tab with a single space.

Now, if you look at the test page I attached in IE 6, they do interpret &#10;
as a newline and &#9; as a tab, and although Microsoft is far from perfect when
it comes to standards, I would have to agree that it should be interpreted in
that way...

The reason is: Because its written that way in the spec. Also, since IE honors
this, it would satisfy people that Mozilla and IE had the same method for
adding a newline. When the standard seems ambigious, let's try to keep the
browsers of different groups/companies working the same (i.e. fill in the void
the standard left). We made a mistake in the past not rendering the background
of a table cell when it is empty because the standards said so when it seemed a
little ridiculous (People had to put in 1x1 gif images). Later, they modified
the standard and people still were hesitant about changing it (finally it was
changed). Until they make this less ambigious, let's just do what makes the
most sense from a web developer standpoint. I don't think having a multi-line
tooltip is out of the question. We can still crop each line and limit the
number of lines. In comment #56, there was a good example of when this might be
used. Anyway, if IE interprets &#10; as a newline, does it make any sense to
haggle over what the seemingly ambigious entry in the specs says when we are
only going to hear people complain about their pages "Not working in Mozilla"?

And anyway, it is following what the spec says: "Replace character entities
with characters". Unless you can find a part of the spec that says newline
characters shouldn't be displayed in tooltips, I don't see how it isn't clear
that we should escape &#10;

Therefore:
title="foo&#10;foo"
Display:
+---+
|foo|
|foo|
+---+

Therefore:
title="foo&#9;foo"
Display:
+----------+
|foo foo|
+----------+

It says we should ignore line feeds (which I think by that they didn't mean
"\n" but meant hard lines feeds in the file). Note, again IE doesn't escape \n.

Therefore:
title="foo\nfoo"
Display as:
+--------+
|foo\nfoo|
+--------+

(Same with \t)
It says we should replace each carriage return or tab with a single space. I
think what they meant by that was when you have a CR-LF combination, the CR
should be turned into a space:

title="foo
foo"
Display:
+-------+
|foo foo|
+-------+

title="foo (tab) foo"
Display:
+-------+
|foo foo|
+-------+

....And notice how IE shows a nasty little blocky TAB char for:
alt="foo&#9;foo"
Let's not r...

Nav triage team: nsbeta1-

I totally agree with Brian's comment 71. Explicit newlines (entities) should be
honored, "implicit" newlines converted to spaces. Bug 47078 should deal with the
conversion, and in this bug, the issue of making the explicit newlines work
should be addressed.

It seems that this bug's dependence is the other way around: this _depends_ on
bug 47078, and not vice versa.

BTW, see also bug 45375 - "tooltips should wrap".

Here is another page regarding tooltips:

http://www.petesguide.com/WebStandards/tests/tooltips.html

*** Bug 45375 has been marked as a duplicate of this bug. ***

I too agree with Brian's <a
href="http://bugzilla.mozilla.org/show_bug.cgi?id=67127#c71">comment 71</a>. We
need a multi line comment and the way of IE is good for us. I think that Mozilla
could go the some way. IE is less standard browser but is the more used due to
Microsoft bad W3 compliant too. So if Mozilla would replace IE must do what IE do.
For now our client use IE. I hope they will use Mozilla soon ;)

*** Bug 195552 has been marked as a duplicate of this bug. ***

*** Bug 195913 has been marked as a duplicate of this bug. ***

*** Bug 198197 has been marked as a duplicate of this bug. ***

*** Bug 198725 has been marked as a duplicate of this bug. ***

*** Bug 202178 has been marked as a duplicate of this bug. ***

If no one is planning to work on it, you can assign it to me.

finally. Thank you Brian for interesting.

*** Bug 203639 has been marked as a duplicate of this bug. ***

*** Bug 204166 has been marked as a duplicate of this bug. ***

*** Bug 205128 has been marked as a duplicate of this bug. ***

*** Bug 212973 has been marked as a duplicate of this bug. ***

Created attachment 129857
Lame patch

* I don't understand why I have to set the height and width manually
* I can't get this to work in XBL, only in XUL as shown :-(

Comment on attachment 129857
Lame patch

Just looking for comments.

I'm actually working on something similar, but for HTML tooltips :)

I think its a hack, wouldn't it be better to:

  - parse the text for newlines
  - create seperate dom nodes for each "line"?

Note that the embedding tooltip api works correctly :)

Created attachment 129862
Newline-only patch

This version makes all tooltips multiline by splitting on newlines but it
doesn't handle tabs.

Neil: why not do the xbl in the setter for the label property?

I agree with comment 71. So with character entities being turned into their
character equivalents, at the DOM end we'll see CRLFs and TABs, right? Then
Neil's patch is a good start (if not the answer), and until bug 47078 is fixed,
we'll get the complete IE behaviour (modulo "bugs") for free. Once bug 47078 is
fixed though, CRLFs in the HTML will become spaces and some of these
testcases/sites will stop working as expected (note that IMHO the expectation is
wrong). Do we want to introduce this now and "break" things later, or should we
wait till bug 47078 is fixed?

jag: which way do you like better, the pre css one or the splitting version?

I am sorry, but as I discovered that this Bug, Misbehaviour or "not running
along with IE" is a open bug since 2001/01, I am quite disapointed about Mozilla.

So many discussions and no solution to a simple problem, which affects a lot of
sites and make them hard to use/read, is undescribable situation.

Could some please get rid of this Bug... PRETTY PLEASE?

Re Comment #95 (and anymore potential Me To's)

At the top of this bug report, you can see that a patch was attached by Neil on
15/8 (15 August) and is undergoing the official Mozilla review process.

Yes, this bug has been around for a while, but I notice that the patch is from
someone who is "officially" not part of Mozilla, but is a programmer somewhere
who decided to have a go at fixing the problem.

While I haven't encountered this bug myself, I thank Neil for his unpaid work on
fixing it for all of us.

NEIL: Shouldn't this bug be Assigned to you?

There is no reason for the bug to be assigned to Neil unless he wants it and Jag
wants to assign it to him. Assigning it to him wouldn't make much of a difference.

How about shutting up and letting people fix bugs quietly? What a novelty...

This semi works (popup.xml):

   <binding id="tooltip" extends="chrome://global/content/bindings/popup.xml#popup">
     <content>
- <children>
- <xul:label class="tooltip-label" xbl:inherits="value=label,crop"
crop="right" flex="1"/>
- </children>
+ <xul:label style="white-space: pre;" class="tooltip-label"
xbl:inherits="xbl:text=label,crop" crop="right" flex="1"> </xul:label>
+ <children />

Just the height/width is still messed up, for which Neil has a (albeit somewhat
ugly) workaround. Not sure why the original code had the anon content inside
the <children> tag though.

What Doron Rosenberg is saying (in a not so polite manner - though I think it
wasn't meant to be rude, just humerous ;-) ) is that complaining in a bug will
not make it fixed any faster when there is already a patch available.

re Comment #98.

You're right, I should just accept patches quietly, and be just as quiet about
any new bugs. I shouldn't thank people for their work as I must be quiet. I
shouldn't bother doing any testing as it achieves nothing as I must be quiet.

I should not file a Bugzilla bug regarding a problem which I noticed with this
bug report as I must be quiet.

You don't have to be quiet. Its just since this bug is currently being reviewed,
etc, so it can't move any faster than it is. We have a limited number of reviewers.

By all means, you can thank people, but also its probably better to do that
through private email unless you want to thank everyone that worked on the bug.
At least half the patches or more are worked on people that aren't official
members of the foundation.

I think doron was more responding to this:
> Could some please get rid of this Bug... PRETTY PLEASE?

You must realize we have had some bugs "spammed out" by people complaining, etc
and not really adding any implementation details, etc. Bugzilla is more for
developer conversations than for advocacy, etc. That's what votes are for
(although we should have a way for people to provide info on why they voted a
certain way as they vote, and there is a bug for that).

doron was just trying to prevent this bug from being off-topic. There isn't any
reason you should take it personally. This stuff happens all the time, and some
developers have less patience than others.

I should have emailed privately to you, but I wanted to also have it here for
the benefit of other people who might have been offended.

hyatt on irc suggested (to fix the sizing issue) to not use xbl:text but just
change the textnode myself (or so I understood from him) - now the tooltip
doesn't even show up at all.

Created attachment 130594
semi working patch, seems to kill UI tooltips though

bryner, any idea why we need to reset the height to the boxObject height?

What is the height before you do that? 0?

Its the height of one character (original height I believe)

*** Bug 218873 has been marked as a duplicate of this bug. ***

About duplicate Bug 218873. i do not get black bars as shown in a screen shot
for this bug - i get squares. Though this may just be due to system font etc.

Just thought might be worht mentioning.

P.s. Sorry about duplicate - but i couldn't search for black bars/lines if i
didn't get em :)

Comment on attachment 129862
Newline-only patch

I prefer this approach.

Interested developers please have a look at
http://forums.mozillazine.org/viewtopic.php?t=38949

Taking

Accepting

Created attachment 136944
New Patch v0.1 - based on newline-only patch

This patch does several things:
1/ Converts \n, \r and \ t to the appropiate control character
2/ Deals with LF, CR and combinations there of
3/ Replaces tabs with 8 spaces
4/ Wraps lines longer than 64 characters at the last space before the 64th
character (bug 45375) - there are probably better ways to do this

Comment on attachment 136944
New Patch v0.1 - based on newline-only patch

This patch was based on Neil's newline patch so someone else needs to review
it.

Comment on attachment 136944
New Patch v0.1 - based on newline-only patch

r=jag

Comment on attachment 136944
New Patch v0.1 - based on newline-only patch

sr=bzbarsky

Comment on attachment 136944
New Patch v0.1 - based on newline-only patch

Requesting approval to get into 1.6beta - fairly low risk but really needs to
go into beta and not final

Won't the following section of the patch only replace the first instance of each
of these characters?
+ label = label.replace("\\n", "\n");
+ label = label.replace("\\r", "\r");
+ label = label.replace("\\t", "\t");
Shouldn't it use a regex like label.replace(/\\n/g, "\n") instead? There's no
guarantee that there will be only one of these characters, right?

+ // replace all control characters except LF, CR and tab with ?
+ label = label.replace(/[\x00-\x08]|[\x0B\x0C]|[\x0E-\x1F]/g, "?");

Could we replace them with U+FFFD instead?

+ label = label.replace("\\n", "\n");
+ label = label.replace("\\r", "\r");
+ label = label.replace("\\t", "\t");

I assume this doesn't actually convert literal "\n" characters in HTML
attributes into newlines. The following:

   <span title="yes\no">test</span>

...should render with the following tooltip:

   [ yes\no ]

...not:

   [ yes ]
   [ o ]

...right?

Comment on attachment 136944
New Patch v0.1 - based on newline-only patch

Minusing approval request since the patch needs work.

Re comment#120
erm good point don't why I didn't pick that up

Re comment#121
ok I'll spin a patch that uses \uFFFD instead of "?"
it was my understanding that we did actually want to convert the literal "\n"
characters but I can take that out.

My understanding was that "&#10;" should be converted into \n and "&#13;" into
\r. (See comment #62.)

Created attachment 137054
New patch 0.1.5

This patch is a slight modification to the previously-submitted patch:

* Uses U+FFFD replacement character for unknown control characters instead of
plain "?"
* Removes code that replaces "\n" and "\r" character sequences (see comment 62)

Ian: Why You don't want to have

<span title="yes\no">test</span> displayed as

[ yes ]
[ o ]

??? I think it's much better way to write line break than

<span title="yes
o">test</span>

Isn't it?

Because the spec doesn't even remotely say anything about doing that?

Comment #51 proves that title is CDATA. If so, here we are with CDATA:
http://www.w3.org/TR/html401/types.html#type-cdata
According to this, we shouldn't break lines at all.
If it will be in Gecko I think that when somebody types "text\ntext" he rather
want to break line than display this directly.

Zbigniew:

\n and \r are line-breaks for C printf and scanf statements, along with perl. In
C++, you use character-code entities for line-breaks, read (from the spec):

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

That is pretty clear. \n is simply text, and shouldn't be interpreted as
anything else, since \ is not an escape character in CDATA. Line feeds appear as
spaces, and only thing that gets interpreted are character entities, like &gt;

Therefore, we should use character entities to insert line-breaks in titletips,
and if IE does anything extra (like interpret \n), they are doing it wrong.

<span title="yes
o">test</span>

According to the spec, line-breaks in the HTML file itself appear as whitespace,
so that should appear as "yes o" all on one line.

From my testing
<span title="yes&#10;no">test</span>
seems to get interpreted the same ways as
<span title="yes
no">test</span>

Which is where bug 47078 comes in I presume?

Ian: I haven't played with the patch, nor is the spec very helpful when it comes
to character entities (they should mention how to handle character entities such
as line-feed and carriage return in specific cases like attributes.

This is my interpretation of what you should see:
<span title="yes&#10;no">test</span>

+---+
|yes|
|no |
+---+

<span title="yes
no">test</span>

+------+
|yes no|
+------+

This whole thing is where we run into a bit of something that isn't quite talked
about in enough detail in the spec. I'll give you a my interpretation:

* &#10; is the character code for line-feed, not a line-feed itself.
* We should honor &#10;, but ignore hard line-feeds of ascii char 10 (like you'd
get from a text editor).
* &#13; -- I have no clue what we should do with this, perhaps we should just
replace it with a space (This isn't specified anywhere that I can see).
* Ascii char 13 (hard carriage returns) should be replaced with a space.

I think they should provide more information on differentiation between
character codes and ascii chars for special print characters, but if IE and we
do it the same way, it'll become a de-facto standard.

Although the initial comment in bug 47078 referred to line breaks being replaced
with nothing, it might be the same issue. It depends on if the same patch would
handle both cases (if there is an issue). You'd have to look at the code.

Hixie:

Can w3c provide more details about this in the future? When it comes to
character codes for special chars in attributes and regular document text, there
seems to be a lot of grey area.

Correction:

I meant "printf and sprintf" in comment 129, not "printf and scanf".

Just want to express agreement with Brian about the desired behavior:

<span title="yes&#10;no">test</span>

+---+
|yes|
|no |
+---+

<span title="yes
no">test</span>

+------+
|yes no|
+------+

In addition - &#13; &#10; and &#13;&#10; should all produce only one line break,
and hard character sequences 13, 10, and 13-10 should all produce only one space.
(This is to handle the \r and \r\n newline conventions used by older MAC and DOS
respectively.)

I agree with both Brian and Zack. See previous comments in this thread. Reading
Hixie's comment 121, I now disagree with my comment 49, \n should just be
displayed as the literal "\n", not as a newline. See comment 93 for what I think
should happen, and has been mentioned elsewhere, any newline chars should be
treated as whitespace (currently blocked by bug 47078), the entity &#xA; (or
perhaps all of &#xA;, &#xD; and &#xD;&#xA;) should be turned into a newline and
displayed as such in our tooltips.

Comment on attachment 137054
New patch 0.1.5

>+ var vbox = document.getAnonymousElementByAttribute(this, "anonid", "vbox");
>+ if (vbox) {
>+ while (vbox.lastChild)
>+ vbox.removeChild(vbox.lastChild);
>+ // replace all control characters except LF, CR and tab with \uFFFD
>+ label = label.replace(/[\x00-\x08]|[\x0B\x0C]|[\x0E-\x1F]/g, "\uFFFD");

Forgot to mention this last time, but could this become something like:
/[\x00-\x08\x0B\x0C\x0E-\x1F]/g?

>+ // replace tabs with eight spaces
>+ label = label.replace(/\x09/g, " ");
>+ var labels = label.split(/\n\r|\n|\r\n|\r/);

Hmmm, I don't think I've seen \n\r. For a moment I was afraid it could take
\r\n\r\n (two DOS newlines) as three newlines by matching \r, \n\r, \r, but in
the matching order it would of course match \r\n before matching \r, and never
see the \n\r combination.

r=jag

&#13; (&#xD;) shouldn't do anything special. Since this patch is converting some
control characters to U+FFFD, it should do the same with U+000D.

Only U+000A inserted by character entity should become a line break.

I still don't understand why we're doing the control code conversion thing, nor
do I understand how it is being done, or why only a subset of UNICODE control
characters is being converted. Why is that special cased at all? Shouldn't the
existing code in layout or GFX take care of this?

In any case, if DOM/JS uses UTF-16, isn't the following:

   label.replace(/[\x00-\x08]|[\x0B\x0C]|[\x0E-\x1F]/g, "\uFFFD");

...going to completely corrupt the output? I really don't understand that part
of the code to be honest.

Similarly, TAB characters should just be handled by layout; if they're not
that's a layout bug too (I'm assuming the tooltip has white-space: pre).

Created attachment 137112
New patch 0.1.6

New patch 0.1.6, without the general control character substitutions.

I can't argue against removing the general control character substitutions,
although in my tests, it didn't corrupt UTF-16 data. IE6 does something like
it, but I don't know that it's necessary.

IE6 appears to match the newline patterns in Ian Neal's patch (\r, \n, \r\n,
and \n\r). I think it's a good idea to keep those patterns to make life easier
for users with pages using title attributes.

Tab characters are apparently not handled the way Hixie expects. The
replacement in the patch is necessary for spaces to be displayed. As with the
general control character substitutions, there might be a fear that it would
corrupt UTF-16 data, but I can't get it to happen -- I tried the following line
in both UTF-8 and UTF-16:

<span title="this is a &#x909; test">this is a &#x909; test</span><br/>

One of the questions is should we using \uFFFD if JS/DOM is only UTF-16, if not
then should we go back to using "?"

Web page designers might put the control characters in numerical order hence
matching on \n\r as well as \r\n

Slightly offtopic, but I was wondering: Should we be converting &#010; to the
equivalent to <br> within the regular document, and not within an attribute?

<body>
Some text
&#010;
&#010;
&#010;
&#010;
Some more text
</body>

should this appear as the equivalent to:

<body>
Some text
<br>
<br>
<br>
<br>
Some more text
</body>

No, and it's off topic.

I don't understand why tabs are failing. I think we should remove the tab-
specific code here (it doesn't do alignment of tabs, e.g.) and instead file a
bug on getting tabs to work in this case (preferably with a small testcase).

Similarly, if we are trying to emulate CSS rules here, we should not be looking
for U+000D at all, and should only be splitting on U+000A. I don't see how we
could get a U+000D in there anyway unless the author is being silly enough to
explicitly say title="foo &#13; bar" in which case he deserves what he gets.

Any particular reason we're not just rendering this using -moz-pre-wrap? That
would get around most of these problems as far as I can tell (wouldn't be any
need to special case any of this).

> One of the questions is should we using \uFFFD if JS/DOM is only UTF-16, if not
> then should we go back to using "?"

I don't understand this, by the way. What has UTF-16ness got to do with that?

I'll try to get my brain in better order today - I realised almost as soon as I
hit the commit button I'd got myself completely confused on the UTF-16 issue.

Anyway, I've already been testing the use of style="white-space: -moz-pre-wrap;"
within popup.xml and it seems to be completely ignored. Neil also suggested
maybe trying max-width too, but again it has on impact. I tested both with vbox
and label, so not sure what is going on with that yet.

As mentioned in comment #132 older MACs use &#13; but I expect those MACs don't
run OS X so do we need to support that use? Can someone confirm?

To me it looks like we have a couple of choices:
a) Put in a temporary fix to address the issue of this bug within popup.xml and
investigate a more permament fix
b) Forget the temporary fix and just concentrate on the permament fix

The other question is why are control characters other than LF making it this
far - this, I suspect, should be part of the permament fix.

> As mentioned in comment #132 older MACs use &#13;

No, they don't (unless I'm very much mistaken).

They might use U+000D (literal character decimal 13), but they don't use the
escape "&#13;", which is all that should be creating a newline.

Looks to me like we should file bugs on the parser and on the style system to
get the input parsed right (U+000A should become a space and "&#10;" or "&#xA;"
should become a newline) and -moz-pre-wrap rendered right respectively, and make
this bug dependent on them.

Since the patch also provides a fix for bug 45376 which has 88 votes and is very
much desired by many ... why not make a temporary fix or spin off just the
wrapping part so that it gets into 1.6?

Bugzilla Bug 45376 You can make a bug depend on itself. - Verified Fixed

This bug really has a patch that provides a fix for that? impressive.

I think he meant bug 45375, which is related and does currently have 88 votes.

In the meantime, it might be reasonable to check in the patch that would be the
correct fix once those parser bugs were fixed. This would have the advantage
that it gets rid of the unsightly black boxes and that it gives authors a way
(avoid literal newlines in title attributes; use &#x0A;) to get what they want
both in current Mozilla and in a correct Mozilla.

-moz-pre-wrap sounds like a more complex issue since one would need to decide
when to wrap -- I think it's OK to fix this bug without wrapping, for now.
There's no need to fix every problem related to tooltips in a single checkin.

Sorry for the typo, yes Michael I mean bug 45375 (thanks timeless for spamming
this bug with your cynism, unlike Michaels response yours adds nothing
constructive to this bug).

David I agree, but is there anything that would speak against using the fix for
the wrapping issue that exists in this patch at least as a temporary solution
until some alternative method gets worked out?

> since one would need to decide when to wrap

I'd rather we left wrapping up to the web authors on tooltips (talking from the
perspective of a web author this time), because we might cause a wrap when they
don't want it. It would be nice in some cases, though, for really long tooltips
if we could handle it for them and create the tooltip with a width that was good
for their machine. I don't know how we could accomodate both possibilities, though.

How about adding a hidden pref, so users can change the wrap-length, if they
want to? Set this to 64 (or a bit higher?) as a default should be more then ok.
Although I doubt, that many users change the default value it would be nice if
people could. It's better, than hardcoding it and better, than an endless
discussion, how long that should be at the end.

Would relating the width of the tooltip to the width of the window it is being
generated from be a good idea?

Do we want to, temporarily, strip out other control characters that will
generate black bars?

I've logged bug 228099 to do with the parsing of U+000A as opposed to "&#10;" or
"&#xA;" and bug 228100 for the -moz-pre-wrap issue as per comment#143.

Created attachment 137769
Patch v0.4 based on Doron's patch

Tweaks Doron's patch to use white-space: -moz-pre-wrap. Once bug 228673 is
fixed this patch should work.

From comment #151:
> Would relating the width of the tooltip to the width of the window
> it is being generated from be a good idea?
This looks like a good idea to me, unless it's easy to solve.

*** Bug 238889 has been marked as a duplicate of this bug. ***

*** Bug 152157 has been marked as a duplicate of this bug. ***

*** Bug 244185 has been marked as a duplicate of this bug. ***

standsongrace: Please do not add blocking flags; that's for drivers.

I just tested using the &#10; character in my title attribute for a span in both
mozilla and firefox, and they both display a small black vertical bar in win2k,
and in linux I get a junk character. Evidently this isn't being handled
correctly still.

*** Bug 248168 has been marked as a duplicate of this bug. ***

It has been three and a half years since the discovery of this small, yet
annoying bug and it is still there :/ I feel like I'm using software from the
'one and only right company'...

If we can make progress on getting this reviewed and ready for check in we could
consider taking it on the aviary branch. renominate after review.

thanks

*** Bug 113595 has been marked as a duplicate of this bug. ***

I wonder, if Bug 47078 (Newlines are not converted to whitespace in attributes)
and Bug 227099 (Parse U+000A, "&#10;" and "&#xA;" correctly in attributes)
should still be blockers for this bug? Both are wontfixed.

*** Bug 253899 has been marked as a duplicate of this bug. ***

Is there any chance that we could temporarily apply a _partial_ patch to this?
That is, could we create a patch that would eliminate the actual problem
(strange characters in the tooltip when there just happens to be a line break in
the HTML) without worrying about adding these new features (change the
underlying implementation to allow multi-line tooltips)? My impression is that
the difficulties with the current patch are only on the "feature enhancement"
side of the issue.

*** Bug 264570 has been marked as a duplicate of this bug. ***

Is it really necessary to replace control characters with U+FFFD or "?" here?
Why assume the user's font doesn't have a meaningful glyph for these characters?
 If that substitution is normal/desirable, why isn't it happening in the
rendering code instead?

If the goal is simply to avoid the "black bars" and replace them with the
Unicode REPLACEMENT CHARACTER instead, this seems misguided. If authors have no
business specifying control characters in their text, it shouldn't matter if the
font's glyph for that character is a square/black bar. The real problem here is
that authors felt they *do* have business putting newlines in their "title"
attributes. I'm not sure a blanket control character substitution is
appropriate as it doesn't appear to be fixing the (right?) problem.

Just seen it with
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a5) Gecko/20041020 Firefox/0.9.1+
the newlines in source code are displayed by some block graphics charcters.

*** Bug 266448 has been marked as a duplicate of this bug. ***

Always here in Firefox 1.0 final ...

*** Bug 269495 has been marked as a duplicate of this bug. ***

*** Bug 272573 has been marked as a duplicate of this bug. ***

*** Bug 273144 has been marked as a duplicate of this bug. ***

It's not so much a case of authors putting significant newlines in their titles as it is a case of
insignificant whitespace (as is allowed all through HTML / XHTML) being contained within titles.
Consider an acronym tag like: <acronym title="This Is A Longer Than Average Acronym Being Used As
An Example">TIALTAABUAAE</acronym>. Theoretically the XHTML author could break this beast up
pretty much anywhere and still have it display the same thing (and in fact programs like Tidy will
happily break it up to keep individual line lengths under control) and while most rendering engines will
do the right thing, Gecko will display black bars.

. o O (looking at the date this bug was reported I feel this debate is nothing
but academical :o)

This is considered a valid bug, or it would be marked invalid. It's just not a
high priority bug, and the solution is not so clear from the standards. There is
a patch if anyone would like to dust it off.

Wrapping the title is not a good idea because people might want to show a
pre-formatted title, like ASCII art or something less silly :-)

*** Bug 273768 has been marked as a duplicate of this bug. ***

*** Bug 273854 has been marked as a duplicate of this bug. ***

*** Bug 275450 has been marked as a duplicate of this bug. ***

(In reply to comment #177)
> Wrapping the title is not a good idea because people might want to show a
> pre-formatted title, like ASCII art or something less silly :-)

I don't think that usage (at least with carriage returns and/or linefeeds) is allowed in standard HTML.
The spec says that:

'''For all HTML elements except PRE, sequences of white space separate "words" (we use the term "word"
here to mean "sequences of non-white space characters"). When formatting text, user agents should
identify these words and lay them out according to the conventions of the particular written language
(script) and target medium.'''

and goes on further to say that:

'''In particular, user agents should collapse input white space sequences when producing output inter-
word space. This can and should be done even in the absence of language information (from the lang
attribute, the HTTP "Content-Language" header field (see [RFC2616], section 14.12), user agent
settings, etc.).'''

It identifies characters: space (&#x0020;), tab (&#x0009;), form feed (&#x000C;), zero-width space
(&#x200B;), carriage return (&#x000D;), and line feed (&#x000A;) as white space characters. No
exception is made for the title attribute. This is why standard (and extremely widespread) tools like
Tidy freely break up long titles across multiple lines. Authors expecting to preformat title attributes
with spaces, tabs, form feeds, zero-width spaces, carriage returns, and line feeds are expecting a
behavior that's seemingly at odds with the specification.

However, the spec also states that:

'''This specification does not indicate the behavior, rendering or otherwise, of space characters other
than those explicitly identified here as white space characters.'''

so preformatting with other white space characters (e.g., next lines (&#x0085;), line separators
(&#x2028;), paragraph separators (&#x2029;), etc.) is allowed but is still an extension that HTML
authors shouldn't automatically expect to work everywhere.

We shouldn't be holding up a fix for something that is an obvious, blatant, embarrassing bug that even
shows its bad behavior on the W3C site because some Web page authors (I believe a minority) are
currently relying on unspecified behaviors. I'm all in favor of adding support for preformatted titles
using next lines, etc., but it should be done at a later date and probably via a separate feature request.
The bug should be fixed first, and the enhancement added later.

Feneric, it looks like you're confusing characters and character entities. See
comment 131 for what everyone seems to agree is the correct behaviour. It's
just a matter of getting the code patched to do that!

First, it's only just hit me that this bug was first reported in the context of
ALT text for images, but the current summary and the existing patches for the
problem apply only to tooltips. Given that newlines in ALT text are still
handled improperly (just tested with Firefox 1.0 on Win98), is there any bug
still dealing with that (and with newlines handled improperly in other
attributes), or should a new one be filed? It seems like many of the ideas
being implemented here should apply generally to all attributes (though bug
228099 comment 7 points out why quirks mode should avoid these replacements for
the "value" attribute, at least).

And second, in reply to comment #182:
> Feneric, it looks like you're confusing characters and character entities. See
> comment 131 for what everyone seems to agree is the correct behaviour. It's
> just a matter of getting the code patched to do that!

It looks to me like Feneric's point is essentially the same one that I made in
comment 166. This bug started life as a request to honor the HTML specification
by treating whitespace as whitespace rather than changing some of it into
visible characters. But at some point, it evolved into a worthy but rather
different enhancement request to enable pre-formatted (multi-line) tooltips
using explicit character entities.

I agree that this enhancement is a valid and useful reading of the
specification! But I'm not convinced that the two issues are related, either
conceptually or in the code. As I understand it, solving the original problem
should just be a matter of replacing every block of whitespace in a title
attribute with a single space ("s/\w+/ /g", I think), and there's probably
already code somewhere that does that ("white-space: normal" in CSS, for
instance). Even if it's not quite that easy, the original problem can't
possibly have anything to do with the current blocking bug 228673 (which
wouldn't arise here at all without patch v0.4's change to browser.js that
enables multi-line tooltips).

In short, it looks to me like the original bug could probably be fixed without
too much trouble by those who know the code. (Please correct me if that's
wrong!) But instead, that fix is being incorporated into a complicated
enhancement with a fairly low apparent priority. So why not spin off the
enhancement into its own bug (or if it's easier at this point, create a new bug
for the original issue and relabel this one), and in the meantime check in a fix
for the original problem?

FWIW that latest patch is still valid, just the line numbers have changed. I
tried it and it worked fine, except for a problem I noticed with 'normal'
tooltips. If there was no newline in the title attribute, the tooltip box was
twice as high as it needed to be. Something like this would fix it:

if (t.search(/\n/) >= 0) {
  tipNode.setAttribute("height", tipNode.boxObject.height);
}
else {
  tipNode.setAttribute("height", tipNode.boxObject.height - 16);
}

I'm sure the height of the tooltip (16 on my PC) is stored somewhere else and is
not a fixed value.

And although I agree with much of comment 183 that this bug has gotten off
track, it's only a 2 or 3 line fix that would solve the original problem! Why
doesn't someone do it! (I've got no idea how to make one of those diff files,
otherwise I'd give it a go myself.)

*** Bug 277528 has been marked as a duplicate of this bug. ***

*** Bug 278848 has been marked as a duplicate of this bug. ***

*** Bug 278972 has been marked as a duplicate of this bug. ***

*** Bug 280167 has been marked as a duplicate of this bug. ***

Created attachment 173547
acronym testcase (LF+TAB)

A testcase for acronym tooltip with \n(LF) and \t charcters inside.

*** Bug 287094 has been marked as a duplicate of this bug. ***

*** Bug 216592 has been marked as a duplicate of this bug. ***

*** Bug 67127 has been deleted, removed due inactivity. ***

/Sarcasm End

Since more than 4 years a bitterly fight goes over an tiny problem.
But this problem got some powder in itself and nevertheless it threatens to
split a religion and couse civil war, disaster and a lot of death.
Why? Cause it means, W3C seen as pontifex of WWW is unfailable and not
questionable. Or should the masses get their rights and tell and use learned
methods for themselfs, without considering the wishes of the wise and lonely top?

I estimate we have an answer to a problem in 5 more years, which solved itself
due time automatically.
And everybody, who dont wont to wait this long period of war, I tell:
http://piro.sakura.ne.jp/xul/_popupalt.html.en#download

Maybe, this brave act of an civillian will help us to lead the pontifex W3C to a
better way of understanding of their people.
(Well, me personaly think, nope, but we must provide a positive way for our W3C.)

PS: Couldnt stop me from writing this, since I look up this matter for a long
time now.
*Flame start here*

*snort*hahahahaha*snort*

Sorry, you commented in the wrong bug, this is not the alt-as-tooltip bug.

Yeah, but Piro's extension fixes this bug too. Actually when this bug started
Moz could still display ALT text as evidenced by the first test case which is
demonstrating the "black bars". Black bars that are not even visible now because
the ALT text is not displayed.

Perhaps that makes this bug "invalid"

(In reply to comment #194)
> Yeah, but Piro's extension fixes this bug too. Actually when this bug started
> Moz could still display ALT text as evidenced by the first test case which is
> demonstrating the "black bars". Black bars that are not even visible now
> because the ALT text is not displayed.

I don't follow you. Mozilla _does_ display ALT text, and always(?) has: when
the image is unavailable or when it hasn't loaded yet. That's what ALT text is
for: an alternative way of conveying image content. (And that's pretty clearly
the context of the original report, which mentions that the display of the text
is different depending on whether the image is still trying to load or whether
Mozilla has given up.) As I said in comment #183, I've tested this myself with
Firefox 1.0 and the ALT text bug is still there (as is the tooltip problem, of
course).

I've just tried. Firefox doesn't display the alt text when the images are not
displayed.

(In reply to comment #196)
> I've just tried. Firefox doesn't display the alt text when the images are not
> displayed.

Did you try the original reporter's testcase? (That is, create a local file
whose contents are the HTML snippet he gave: the linked testcase URL for the bug
was apparently changed to a tooltip example at some point.) I've got that case
open in another tab right now (Firefox 1.0.1 on OS X), and the ALT text is
shown, strange box characters and all.

OK, Firefox displays the alt text only when the images are shown (I don't think
this condition is a good idea, since the goal of the alt text is to give some
information when the image is not visible, but well...).

*** Bug 292990 has been marked as a duplicate of this bug. ***

XML 1.0 spec., section 3.3.3 Attribute-Value Normalization sais:

For a white space character (#x20, #xD, #xA, #x9), append a space character
(#x20) to the normalized value.

So I think that no new line in attribute can be rendered (at least in XHTML).

I´m not sure I see the reason for this year-long discussion - the specs state
clearly that newlines and similar are to be replaced with white-space. The
reason probably being that such characters aren´t valid in all
encodings(Win/Unix for example).

Nowhere it says that a browser mustn´t break long lines - shouldn´t a tooltip be
handled the same way regular HTML is? I.e. if it´s too long for one line - break it.
There is no way an author can know in advance how many characters he can use -
so breaking the line at window-end seems to be the only reasonable solution -
and it´s something the UA has to do, not the web-author.
(Sorry if I repeated what someone else said - I didn´t read the entire thread, I
skipped portions.)

(In reply to comment #201)
> I´m not sure I see the reason for this year-long discussion - the specs state
> clearly that newlines and similar are to be replaced with white-space. The
> reason probably being that such characters aren´t valid in all
> encodings(Win/Unix for example).
>
> Nowhere it says that a browser mustn´t break long lines - shouldn´t a tooltip be
> handled the same way regular HTML is? I.e. if it´s too long for one line -
break it.
> There is no way an author can know in advance how many characters he can use -
> so breaking the line at window-end seems to be the only reasonable solution -
> and it´s something the UA has to do, not the web-author.
> (Sorry if I repeated what someone else said - I didn´t read the entire thread, I
> skipped portions.)

I'd suggest to direct your attention to comment #62, which BTW perfectly
describes my own opinion as I don't like idea of violating the standards yet I'm
sure web-authors definetely should have the possibility of breaking line at a
particular position.

2 Questions:
1. What is 'Patch v0.4 based on Doron's patch' exactly doing? It it doing, what
has been suggested in Comment #62 and/or Comment #71?
2. Why wasn't review or superreview being requested for this patch?

*** Bug 296920 has been marked as a duplicate of this bug. ***

(In reply to comment #203)
> 2 Questions:
> 1. What is 'Patch v0.4 based on Doron's patch' exactly doing? It it doing, what
> has been suggested in Comment #62 and/or Comment #71?
> 2. Why wasn't review or superreview being requested for this patch?

The answer to 2 is that either it doesn't work, or isn't acceptable for some
reason. I don't recall the details, but there are some subtleties here. If I
remember correctly, Neil rejected the patch on IRC. Explicitly messing with the
boxObject.height is almost certainly not the correct solution.

For the record, Ubuntu bug http://bugzilla.ubuntu.com/show_bug.cgi?id=12998 is
the same bug as this one, with another test case, another use case, and another
sarchastic comment (comment #3)

*** Bug 313154 has been marked as a duplicate of this bug. ***

*** Bug 321593 has been marked as a duplicate of this bug. ***

As I suggested in comment 183, I have just spun off the originally reported issue in this bug (regarding black boxes in images' ALT text) into bug 322413. Both that new bug and this one are now set to depend on bug 322270, which I recently filed to deal with whitespace in attributes generally.

After those changes, it might be reasonable to make this bug's summary reflect its current focus: enabling multi-line tooltips. (But it should probably still mention the black bar problem, too, to help people find the problem.) I'll leave it to the bug owner to make that decision.

This bug is still open. Cmon guys - lets fix it before its 6th anniversary ;-)

(In reply to comment #210)
> This bug is still open. Cmon guys - lets fix it before its 6th anniversary ;-)
>

You got a patch?

(In reply to comment #210)
> This bug is still open. Cmon guys - lets fix it before its 6th anniversary ;-)

To summarize the current status of this bug:

The "black bars" problem will be (essentially) fixed as soon as bug 322270 is fixed. That bug's owner has set a target milestone of mozilla1.9alpha, which I believe means "in time for Firefox 3". (It sounds like there may be some fairly low-level changes involved, which may be more than the 1.8 branch is expected to handle at this point.)

The "multi-line tooltips" enhancement that's also been discussed in this bug is a somewhat independent issue. If bug 322270 is fixed in a way that allows the desired behavior in comment 131, then the parsed value of the "title" attribute will include actual line feed characters for each "&#10;" in the source. We'll then want the tooltips themselves to behave something like "white-space: -moz-pre-wrap" as suggested in comment 140 (though wrapping tooltips may deserve a separate bug).

As I see it, the main danger in implementing the eventual fix for multi-line tooltips before bug 322270 is fixed is that page authors might mistakenly think that we were endorsing the standards-violating MSIE behavior (and get upset when the eventual fix limiting them to the method in comment 131 landed). But if anyone can make a patch for this work, we'd all love to see it.

Extension Popup ALT Attribute fixes this bug for me and enables multi-line tooltip. I didn't had any strange behavior with it, so it maybe can help with fixing those bugs.

Created attachment 210603
Interim patch: collapse whitespace (no multi-line)

This patch eliminates the "black bars" in tooltips (only) by collapsing whitespace when the tooltip text is retrieved. It makes no attempt to enable multi-line tooltips, and in fact it will need to be reverted for that to happen.

That being said, this fix removes an ugly behavior that's a blatant Firefox bug and replaces it with a behavior consistent with the HTML standards. The effect of this patch in practice will be essentially identical to the effect of a fix for bug 322270 (with or without any patch here). And since that bug's current target makes it unlikely that a real solution here will be possible before Firefox 3, maybe this fix would be reasonable to include in the meantime.

Thoughts?

Comment on attachment 210603
Interim patch: collapse whitespace (no multi-line)

I won't be able to get to this within any sort of reasonable time frame... Please ask someone else for sr?

*** Bug 326049 has been marked as a duplicate of this bug. ***

Comment on attachment 210603
Interim patch: collapse whitespace (no multi-line)

If I'm asking the wrong person for branch approval, let me know.

Also, I don't have a CVS account, so I will need someone else to actually land this (whether on trunk or on branch).

*** Bug 331016 has been marked as a duplicate of this bug. ***