Newline in tooltips (title attribute) converted to black bars

VERIFIED FIXED in seamonkey1.1beta

Status

SeaMonkey
UI Design
--
minor
VERIFIED FIXED
17 years ago
4 months ago

People

(Reporter: Michael Percy (obsolete email address), Assigned: Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com])

Tracking

({compat, fixed-seamonkey1.1b, testcase})

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(7 attachments, 7 obsolete attachments)

9.77 KB, image/jpeg
Details
238 bytes, text/html
Details
2.91 KB, text/html
Details
2.00 KB, patch
Details | Diff | Splinter Review
367 bytes, text/html
Details
742 bytes, patch
Brian Ryner (not reading)
: review+
dbaron
: superreview+
Brian Ryner (not reading)
: approval-branch-1.8.1+
Details | Diff | Splinter Review
2.65 KB, patch
Details | Diff | Splinter Review
See description and URL: pretty self-explanitory.

Note: if the above URL loads quickly and you do not see the ALT text, put this 
into a file and view it:
--
<HTML><BODY><IMG width="300" height="100"
src="http://blah.com/tmp/nowhere.gif" ALT="See the 
 
 Black Square(s)?"></BODY></HTML>
--

At the testcase URL, IE5 renders the top ALT text as:
     O'Reilly Open Source Software
     Convention

Moz renders it as:
     O'Reilly Open Source Software |Convention
(with the | representing a black square)

This is on WinNT4 SP6. Interestingly enough, when the image times out the 
display of the ALT text is changed to render as inline HTML would. I'm not sure 
what the spec says about this, but IE5's rendering makes more sense to me than 
the "inline HTML" way, but either is better than this. Seeing this in Build 
2001-01-30-04-Mtrunk on NT4.

Comment 1

17 years ago
no black square on linux build 2001-01-29-08.  Could this be windows-only?
(Reporter)

Comment 2

17 years ago
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

Comment 3

17 years ago
Confirmed
Platform: PC
OS: Windows 98
Mozilla Build: 2001012904

Marking NEW.
Severity: normal → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 4

17 years ago
cc ian

Comment 5

17 years ago
Triaging karnaze's bugs.
Assignee: karnaze → kmcclusk
Target Milestone: --- → mozilla1.1

Comment 6

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

Comment 7

17 years ago
Created attachment 33161 [details]
Newline in title of anchor renders as black squares on WinME

Comment 8

16 years ago
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 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
Reopening, this bug is still valid for quirks mode.
Status: RESOLVED → REOPENED
Keywords: compat
Resolution: DUPLICATE → ---
*** Bug 98120 has been marked as a duplicate of this bug. ***
Changing summary to accomodate duped bug (same underlying problem)
Summary: Newline in ALT attribute of IMG tag causes black square to be displayed → Newline in tooltips converted to black bars
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>

Comment 14

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

Comment 15

16 years ago
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 [details]
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.
Blocks: 47078
Keywords: mozilla1.0, testcase
OS: Windows NT → All
Hardware: PC → All
Reassigning to XPTOOLKIT
Assignee: kmcclusk → hyatt
Status: REOPENED → NEW
Component: Layout → XP Toolkit/Widgets
QA Contact: petersen → jrgm

Comment 20

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

Comment 21

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

Comment 22

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

Comment 23

16 years ago
*** Bug 122210 has been marked as a duplicate of this bug. ***
*** Bug 132252 has been marked as a duplicate of this bug. ***

Comment 25

16 years ago
*** 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. ***

Comment 29

15 years ago
*** Bug 154160 has been marked as a duplicate of this bug. ***
*** Bug 156133 has been marked as a duplicate of this bug. ***

Comment 31

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

Comment 32

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

Comment 33

15 years ago
yes, it's me :)
Assignee: hyatt → kyle.yuan

Comment 34

15 years ago
Created attachment 91779 [details] [diff] [review]
let text frame be able to handle multi-line text

Comment 35

15 years ago
CCing alecf, jag, dean to review my patch.

Comment 36

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

Comment 37

15 years ago
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."'

Comment 38

15 years ago
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.

Comment 39

15 years ago
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. 

Comment 40

15 years ago
Tooltips has anything to do with values of form widgets???

Comment 41

15 years ago
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

Comment 42

15 years ago
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 :(

Comment 43

15 years ago
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.

Comment 44

15 years ago
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).

Comment 45

15 years ago
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>

Comment 46

15 years ago
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.

Comment 48

15 years ago
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?

Comment 49

15 years ago
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.

Comment 50

15 years ago
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 ;)

Comment 51

15 years ago
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.

Comment 52

15 years ago
"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.

Comment 53

15 years ago
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?

Comment 55

15 years ago
"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?

Comment 57

15 years ago
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 :(
Keywords: nsbeta1

Comment 58

15 years ago
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.

Updated

15 years ago
Attachment #91779 - Attachment is obsolete: true

Comment 59

15 years ago
=> component owner
Assignee: kyle.yuan → jaggernaut

Comment 60

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

Comment 61

15 years ago
*** 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.)

Comment 63

15 years ago
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.

Comment 64

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

Comment 65

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

Comment 66

15 years ago
nsbeta1+/adt3 per the nav triage team.

Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt3]

Comment 67

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

Comment 68

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

Comment 69

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

Comment 70

15 years ago
*** Bug 184700 has been marked as a duplicate of this bug. ***
Created attachment 109093 [details]
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 replicate that (Embrace and Improve) :-)

Comment 72

15 years ago
Nav triage team: nsbeta1-
Keywords: nsbeta1+ → nsbeta1-
Whiteboard: [adt3]

Comment 73

15 years ago
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".

Comment 74

15 years ago
Here is another page regarding tooltips: 

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

Comment 75

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

Comment 76

15 years ago
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 ;)

Comment 77

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

Comment 78

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

Comment 79

15 years ago
*** Bug 198197 has been marked as a duplicate of this bug. ***
*** Bug 198725 has been marked as a duplicate of this bug. ***

Comment 81

15 years ago
*** 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. ***

Comment 85

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

Updated

14 years ago
Target Milestone: mozilla1.1alpha → ---
*** Bug 205128 has been marked as a duplicate of this bug. ***

Comment 87

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

Comment 88

14 years ago
Created attachment 129857 [details] [diff] [review]
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 89

14 years ago
Comment on attachment 129857 [details] [diff] [review]
Lame patch

Just looking for comments.
Attachment #129857 - Flags: superreview?(jag)
Attachment #129857 - Flags: review?(doronr)
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 :)

Comment 91

14 years ago
Created attachment 129862 [details] [diff] [review]
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?

Comment 93

14 years ago
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?
No longer blocks: 47078
Depends on: 47078
jag: which way do you like better, the pre css one or the splitting version?

Comment 95

14 years ago
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?

Comment 96

14 years ago
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.

Comment 101

14 years ago
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 [details] [diff] [review]
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)

Comment 108

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

Comment 109

14 years ago
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 110

14 years ago
Comment on attachment 129862 [details] [diff] [review]
Newline-only patch

I prefer this approach.
Attachment #129862 - Flags: superreview+

Updated

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

Comment 112

14 years ago
Taking
Assignee: jag → bugzilla

Comment 113

14 years ago
Accepting
Status: NEW → ASSIGNED

Comment 114

14 years ago
Created attachment 136944 [details] [diff] [review]
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

Updated

14 years ago
Attachment #129857 - Attachment is obsolete: true
Attachment #129862 - Attachment is obsolete: true
Attachment #130594 - Attachment is obsolete: true

Updated

14 years ago
Attachment #136944 - Flags: review?(neil.parkwaycc.co.uk)

Comment 115

14 years ago
Comment on attachment 136944 [details] [diff] [review]
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.
Attachment #136944 - Flags: review?(neil.parkwaycc.co.uk) → review?(jag)

Comment 116

14 years ago
Comment on attachment 136944 [details] [diff] [review]
New Patch v0.1 - based on newline-only patch

r=jag
Attachment #136944 - Flags: review?(jag) → review+

Comment 117

14 years ago
Comment on attachment 136944 [details] [diff] [review]
New Patch v0.1 - based on newline-only patch

r=jag

Updated

14 years ago
Attachment #136944 - Flags: superreview?(bz-vacation)

Comment 118

14 years ago
Comment on attachment 136944 [details] [diff] [review]
New Patch v0.1 - based on newline-only patch

sr=bzbarsky
Attachment #136944 - Flags: superreview?(bz-vacation) → superreview+

Updated

14 years ago
Attachment #136944 - Flags: approval1.6b?

Comment 119

14 years ago
Comment on attachment 136944 [details] [diff] [review]
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

Comment 120

14 years ago
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 [details] [diff] [review]
New Patch v0.1 - based on newline-only patch

Minusing approval request since the patch needs work.
Attachment #136944 - Flags: approval1.6b? → approval1.6b-

Comment 123

14 years ago
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.

Comment 124

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

Comment 125

14 years ago
Created attachment 137054 [details] [diff] [review]
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.

Comment 130

14 years ago
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?

Updated

14 years ago
Attachment #137054 - Flags: review?(jag)
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.)

Comment 133

14 years ago
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 134

14 years ago
Comment on attachment 137054 [details] [diff] [review]
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).

Comment 136

14 years ago
Created attachment 137112 [details] [diff] [review]
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/>
Attachment #137054 - Attachment is obsolete: true

Comment 137

14 years ago
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?

Comment 142

14 years ago
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.

Updated

14 years ago
Attachment #129857 - Flags: superreview?(jag)
Attachment #129857 - Flags: review?(doronr)

Updated

14 years ago
Attachment #137054 - Flags: review?(jag)
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? 

Comment 145

14 years ago
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.

Comment 146

14 years ago
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.

Comment 150

14 years ago
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.

Comment 151

14 years ago
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?
Summary: Newline in tooltips converted to black bars → Newline in tooltips (title attribute) converted to black bars

Updated

14 years ago
Depends on: 228099

Comment 152

14 years ago
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.

Updated

14 years ago
Attachment #136944 - Attachment is obsolete: true

Updated

14 years ago
Depends on: 228673

Comment 153

14 years ago
Created attachment 137769 [details] [diff] [review]
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.
Attachment #137112 - Attachment is obsolete: true

Comment 154

14 years ago
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.

Comment 155

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

Comment 156

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

Comment 157

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

Updated

13 years ago
Flags: blocking1.7+
standsongrace: Please do not add blocking flags; that's for drivers.
Flags: blocking1.7+

Comment 159

13 years ago
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.

Comment 160

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

Comment 161

13 years ago
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'... 
Blocks: 251123
Flags: blocking1.8a3?
Flags: blocking-aviary1.0RC1?
Flags: blocking-aviary1.0?
Attachment #137769 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #137769 - Flags: review?(neil.parkwaycc.co.uk)
Flags: blocking-aviary1.0RC1?
Flags: blocking-aviary1.0RC1-
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0-

Comment 162

13 years ago
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

Comment 163

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

Updated

13 years ago
Keywords: mozilla1.0

Comment 164

13 years ago
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.

Updated

13 years ago
No longer depends on: 47078, 228099

Updated

13 years ago
Flags: blocking1.8a3? → blocking1.8a3-
Attachment #137769 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #137769 - Flags: review?(neil.parkwaycc.co.uk)

Comment 165

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

Comment 166

13 years ago
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.

Comment 167

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

Comment 168

13 years ago
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.

Comment 169

13 years ago
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.

Comment 170

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

Comment 171

13 years ago
Always here in Firefox 1.0 final ...

Comment 172

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

Comment 173

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

Comment 174

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

Comment 175

13 years ago
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.

Comment 176

13 years ago
. 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. ***

Comment 179

13 years ago
*** Bug 273854 has been marked as a duplicate of this bug. ***
*** Bug 275450 has been marked as a duplicate of this bug. ***

Comment 181

13 years ago
(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.

Comment 182

13 years ago
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!

Comment 183

13 years ago
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?

Comment 184

13 years ago
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.)

Comment 185

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

Comment 186

13 years ago
*** Bug 278848 has been marked as a duplicate of this bug. ***
*** Bug 278972 has been marked as a duplicate of this bug. ***

Comment 188

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

Comment 189

13 years ago
Created attachment 173547 [details]
acronym testcase (LF+TAB)

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

Comment 190

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

Comment 191

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

Comment 192

13 years ago
*** 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.

Comment 194

13 years ago
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"

Comment 195

13 years ago
(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). 

Comment 196

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

Comment 197

13 years ago
(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.

Comment 198

13 years ago
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...).

Comment 199

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

Comment 200

12 years ago
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).

Comment 201

12 years ago
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.)

Comment 202

12 years ago
(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.

Updated

12 years ago
No longer blocks: 163993

Comment 203

12 years ago
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?

Comment 204

12 years ago
*** 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.

Comment 206

12 years ago
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. ***
No longer blocks: 251123

Comment 208

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

Updated

12 years ago
Depends on: 322270

Comment 209

12 years ago
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.

Comment 210

12 years ago
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?

Comment 212

12 years ago
(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.

Comment 213

12 years ago
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.

Comment 214

12 years ago
Created attachment 210603 [details] [diff] [review]
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?
Attachment #210603 - Flags: superreview?(bzbarsky)
Attachment #210603 - Flags: review?(jag)

Comment 215

12 years ago
Comment on attachment 210603 [details] [diff] [review]
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?
Attachment #210603 - Flags: superreview?(bzbarsky)

Updated

12 years ago
Attachment #210603 - Flags: superreview?(alecf)

Comment 216

12 years ago
*** Bug 326049 has been marked as a duplicate of this bug. ***
Attachment #210603 - Flags: superreview?(alecf) → superreview+

Updated

12 years ago
Attachment #210603 - Flags: review?(jag) → review?(bryner)
Attachment #210603 - Flags: review?(bryner) → review+

Comment 217

12 years ago
Comment on attachment 210603 [details] [diff] [review]
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).
Attachment #210603 - Flags: approval-branch-1.8.1?(bryner)

Updated

12 years ago
Whiteboard: [checkin needed]
Attachment #210603 - Flags: approval-branch-1.8.1?(bryner) → approval-branch-1.8.1+

Comment 218

12 years ago
*** Bug 331016 has been marked as a duplicate of this bug. ***
Patch checked in to both trunk and MOZILLA_1_8_BRANCH, into both browser/base/content/browser.js and xpfe/browser/resources/content/browser.js .
*** Bug 337505 has been marked as a duplicate of this bug. ***
Whiteboard: [checkin needed]

Comment 221

11 years ago
i'd like to add something constructive to this bug. allowing multiline tooltips is a *very* bad idea. eventually someone will create a tooltip that covers your whole screen. i've repeatedly warned gecko people about this.

i'd like to take a moment to note that i've actually seen this happen in a product that happened to ship with gecko (it wasn't the gecko part that did this, but that's not the point). we were in a video conference with a customer and i moved the customer's mouse pointer over some portion of the screen, and all of a sudden, the entire screen flickered yellow for an instant and then went back to normal. this happened a number of times and we really panic'd. we had no idea what was going on, or why.

now, that was when we were dealing with screens that were 1024x768 or larger. the screens i'm looking at today are 800x480. imagine if your screen, which is say ~3"x2" all of a sudden flickers solid yellow. would you be happy?

i wouldn't, and i'd expect my mother and my sister to take their device back to the store and inform them that it's broken and that they want their money back.

not all geckos come for free, sometimes paying customers have valid reasons for complaining about bad decissions.

tooltips should be *short* helpful *tips*, not long discourses about the meaning of the universe. (42 is a valid tooltip, the full transcript about The Answer to Life, the Universe, and Everything, taking a number of volumes and written using pixels on a standard human screen is not a valid tooltip.)

there's a reason that people suggested a LONGDESC attribute to images in addition to the TITLE attribute.

Also to be kept in mind is that as with my example above, tooltips have this tendency of disappearing in response to a timer. if you can't read the tip faster than the timer, then the tip is too long. i've had that problem with the product i described above. the ui designers were nice people, but they didn't consider what would happen when you stuffed lots of text into a small timer.

For people who persist in wanting tooltips, and it's a slippery slope, if i let someone have 4 lines and 30 chars per line, someone will try to get 5 lines and 50 chars, and the next person will use 10 lines and 100 chars. and none of these measurements will fit on my screen. I've been getting a number of bugs in the past few days from people complaining about message texts not fitting into the display. this is a real concern.

stop the slippery slope, don't let tooltips grow beyond one line. if a web designer or any designer needs more than one line to explain something, then the designer has made a huge error and should be forced to rethink it. (oh, and tooltips in general fail to be accessible and are amazingly hard to use on the device with which i'm working, not everyone has a mouse. at this point i rarely have mice. sometimes i have clickable widgets, but the idea of dragging a mouse with me everywhere just to find that someone has left 10 essays hidden throughout his web page is insane.

Comment 222

11 years ago
it occurs to me that this was the wrong bug. i'm sorry. i blame someone else for asking about multiline tooltips and then saying "oh, so why are they fixing this bug" and pointing at this bug. but i'm sorry, i should have remember that this wasn't the right bug. but boy, it's really fun to spam hundreds of people who have voted for the wrong bug.

Comment 223

11 years ago
timeless:

<sarcasm>Are we going to disable DIVs? Because you know they can be huge and can cover your screen on mouseover with yellow (and they say other colors as well).
This reminds me of the JavaScript issue, ...</sarcasm>

Please don't attempt to save the web, and let web-authors make their choice. (Regadrless of what you think about their capabilities.) Applies for length of title-attribute value too.

no offense, have a nice day
  JZ

Comment 224

11 years ago
Re: Comment 221: I strongly disagree. Yes, multi-line tooltips are bad in some scenarios. They are also EXTREMELY helpful in other scenarios. In fact, I have developed an application that relies on these, and of course it won't work with Firefox in its current state.

Design decisions should be made by designers, not forced by the platform developers.
(In reply to comment #223)
> <sarcasm>Are we going to disable DIVs? Because you know they can be huge and
> can cover your screen on mouseover with yellow (and they say other colors as

No, DIVs can cover the part of the browser window in which the Web page is displayed.  That's a smaller area than the screen, and there's a huge difference between the ability to cover one and the ability to cover the other.

(In reply to comment #224)
> Design decisions should be made by designers, not forced by the platform
> developers.

Browsers should be designed for the benefit of their users; sometimes users do need to be protected from malicious authors.  (If you don't believe that, try disabling popup blocking for a bit.)

Comment 226

11 years ago
If browsers are designed for the benefit of their users, then there would be a setting that would limit the number of characters in a tooltip.

But a character cutoff with no redress by the user or the website author, especially when all the other browsers I know of don't have a character cutoff, just doesn't make any sense.

I recommend maximum flexibility for both the user and the website author, in place of the Firefox design team's _hard_ decision to cut off tooltips at a point that pleases only them.
(In reply to comment #225)
> No, DIVs can cover the part of the browser window in which the Web page is
> displayed.  That's a smaller area than the screen, and there's a huge
> difference between the ability to cover one and the ability to cover the other.

Tooltips should not be able to cover more of the screen than the containing Web page is being displayed in, obviously.  Within the bounds set by the client on Web page content, the designer should be able to specify any content he likes to be displayed.
*** Bug 343434 has been marked as a duplicate of this bug. ***
Created attachment 236663 [details] [diff] [review]
What's going on here? [not for checkin]

Neil, why is it wrapping after every single word?  The interesting thing is that if I add a second child to the first label (such as a vbox/hbox that *has size > 0*) it displays exactly the way I want it to (barring the extra child I add, which I don't really want to see).

If I remove the white-space: -moz-pre-wrap using DOMI, then add it back, the tooltip displays properly the first time, but not subsequent times (or it did with a previous version of this patch, where the .hidden code happened at different times).  I also don't understand why that is.
Attachment #236663 - Flags: review?(neil)
(In reply to comment #229)
> Created an attachment (id=236663) [edit]
> What's going on here? [not for checkin]

So, Neil (parkwaycc) didn't know and suggested asking Enn/bz.  bz doesn't care because it's apparently expected to suck when mixing HTML & XUL and he would care only for reflow branch... Enn, any ideas?
Probably because the containing outer label or tooltip doesn't have any size, so the text is laid out as if the width was 0.

That said, I don't think you're going to be able to get the tooltip sizing issues fixed until the reflow branch is done and flexible box work happens.
Attachment #236663 - Flags: review?(neil)
I'm marking this bug fixed and moving it to the product that existed at the time it was filed.  The "real" core fix will happen in bug 322270, but I've more fully taken care of the issue in the UI side for SeaMonkey, and Firefox has had the interim patch for ages, which gets rid of the black bars.  Given the names in the cc list on that bug, I'm satisfied that it is a legitimately useful bug where work can be done.  As far as I can tell, keeping this open doesn't serve any further purpose.  I will file a followup bug on some cleanup for trunk.
Assignee: iann_bugzilla → cst
Status: ASSIGNED → NEW
Component: XP Toolkit/Widgets → XP Apps: GUI Features
Product: Core → Mozilla Application Suite
Target Milestone: --- → seamonkey1.1beta
Depends on: 356900
Fixed in bug 356900 for SeaMonkey.  If I caused any regressions or there are cases where the patch doesn't work, reopen bug 356900, not this bug.  If you don't like the behavior I implemented, file a followup bug (but do *NOT* cc me unless you've contributed at least 1 patch - if you haven't, I probably don't care what you think).
Status: NEW → RESOLVED
Last Resolved: 16 years ago11 years ago
Resolution: --- → FIXED
Keywords: fixed-seamonkey1.1b

Comment 234

11 years ago
Re: Comment #233: That's an interesting attitude. As a developer, you're basically saying: "I don't care what the QA people think (let alone the lowly users)".
(In reply to comment #234)
> Re: Comment #233: That's an interesting attitude. As a developer, you're
> basically saying: "I don't care what the QA people think (let alone the lowly
> users)".
> 

The few good QAs who haven't submitted any patches at all know that it doesn't apply to them.  I really *don't* care what the users think in this case, because there are too many of them, and they have too many different opinions.  On bugs like this, not making it clear that I don't care what users think results in bugs with hundreds of comments and hundreds of cc'ed people, which makes it hard to get work done.

Comment 236

11 years ago
(In reply to comment #232)
> I'm marking this bug fixed and moving it to the product that existed at the
> time it was filed.

I won't object too strenuously to changing the product as you have, but I do find it a little odd: this bug has morphed enormously since it was filed (the original summary was "Newline in ALT attribute of IMG tag causes black square to be displayed"), so insisting on taking it back to its roots in one particular way at this point seems unnecessary and perhaps confusing.  (Especially since the Firefox interim was posted here, too: it might be nice if a search that specified "Firefox" or "Core" would turn this up.)


As for marking it as fixed, I generally agree (given its current summary).  But as I just noted, the bug has morphed substantially since its last summary change: until my interim Firefox patch, the vast majority of the work on this bug would have been better summarized as something like "Enable multi-line tooltips" (I advocated a summary change explicitly in comment 209 and implicitly in several other places).

If you're going to mark it as fixed based on its current summary, you (or, well, someone) really ought to file a bug to cover the issue that has been this bug's de facto focus for the past four years.  Copying over the main conclusions here (comment 131 and perhaps some implementation ideas like the proposed patches or even suggestions like the -moz-pre-wrap idea in comment 140) would be very helpful.  Assuming that that gets done, I completely support this change.
(In reply to comment #236)
> As for marking it as fixed, I generally agree (given its current summary).  But
> as I just noted, the bug has morphed substantially since its last summary
> change: until my interim Firefox patch, the vast majority of the work on this
> bug would have been better summarized as something like "Enable multi-line
> tooltips" (I advocated a summary change explicitly in comment 209 and
> implicitly in several other places).
> 
> If you're going to mark it as fixed based on its current summary, you (or,
> well, someone) really ought to file a bug to cover the issue that has been this
> bug's de facto focus for the past four years.
> 

As I understand it, bug 322270 takes care of the core fix for the black bars, and the reflow branch is supposed to fix all the issues I had to hack around to get the text to wrap properly and the tooltip's size to be correct - I filed bug 357337 to re-address my workaround for the reflow branch situation.  That, I believe, is almost the full story (the rest I addressed in my reply to your comment on the bug where I worked on the patch).

>  Copying over the main
> conclusions here (comment 131 and perhaps some implementation ideas like the
> proposed patches or even suggestions like the -moz-pre-wrap idea in comment
> 140) would be very helpful.  Assuming that that gets done, I completely support
> this change.
> 

I think that currently the behavior specified in comment 131 is not possible to implement, because by the time any tooltip-related code sees the string, the entities (e.g. &#0A; ) are indistinguishable from the values they represent (e.g. \n).  I don't think that requested behavior fits with the spec.  I said more in my reply on the other bug.

Regarding comment 140, doesn't my patch match that?  I think it does, based on my memory (I'm not on a machine that has a patched build right now) of the patch vs. an experiment with -moz-pre-wrap.

Comment 238

11 years ago
Sorry for the spam, but where's the bug for multi-line tooltips in Firefox?  My understanding is that even if the newlines are interpreted correctly by Gecko, Firefox's XUL still needs fixing.  So what's that bug? I'd like to vote for it.

Comment 239

11 years ago
(In reply to comment #238)
> Sorry for the spam, but where's the bug for multi-line tooltips in Firefox?

I've just filed it: it's bug 358452.  I've tried to summarize there the current status of the issue, and the conclusions that were reached here.  It's probably good to have that feature request in its own bug anyway, since this bug's summary was never clearly related to the multi-line enhancement.  (Also note that bug 218223 is closely related: that's the bug for allowing long tooltips to wrap automatically in Firefox.)

Updated

9 years ago
Component: XP Apps: GUI Features → UI Design

Comment 240

8 years ago
The ToolTip Torture Test (see URL) still fails for line breaks but the main issue of this bug is gone. VERIFY. HTML compliance may need another fresh bug.
Status: RESOLVED → VERIFIED
Hb: please see if the remaining issues are covered by bug 358452 and/or bug 322270, and file new bugs if not.

Comment 242

8 years ago
Dependency on bug 228673 and on bug 322270 deleted. This bug here gave an interim fix which was overcome by the one in 322270.

Discussion here circled for more than 4 years around the MSIE vs. Web standards compatibility. During that time new standards arose which made an agreement not easier.

All remaining issues have been filed to bugzilla.
No longer depends on: 228673, 322270

Updated

7 years ago
Comment hidden (spam)
You need to log in before you can comment on or make changes to this bug.