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???

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. ***

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. ***

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.

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.

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

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.)

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
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.

(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.

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.

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).

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.

(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.

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.

(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.)

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.

Hb: please see if the remaining issues are covered by bug 358452 and/or bug 322270, and file new bugs if not.

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.

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.

see also :
https://www.alfransia.com/
https://5star-services.org/

thanks a lot
https://www.ghadeerco.com/
http://albiyoot.com/

Interesting... Looking goodd.

Thanks,
[Bilal](https://techxonic.com)

Solving the multiline tooltip problem was a nightmare those days but now we have a more serious problem than this in programming languages. - <a href="https://appquora.com">AppQuora</a>