Closed Bug 67127 Opened 24 years ago Closed 18 years ago

Newline in tooltips (title attribute) converted to black bars

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
seamonkey1.1beta

People

(Reporter: mpercy, Assigned: csthomas)

References

(
URL
)

Details

(Keywords: compat, fixed-seamonkey1.1b, testcase)

Attachments

(7 files, 7 obsolete files)

Newline in title of anchor renders as black squares on WinME
9.77 KB, image/jpeg
Details
Testcase with character entities for CR-LF
238 bytes, text/html
Details
testcase - view with IE and Mozilla
2.91 KB, text/html
Details
Patch v0.4 based on Doron's patch
2.00 KB, patch
Details | Diff | Splinter Review
acronym testcase (LF+TAB)
367 bytes, text/html
Details
Interim patch: collapse whitespace (no multi-line)
742 bytes, patch
bryner
: review+
dbaron
: superreview+
bryner
: approval-branch-1.8.1+
Details | Diff | Splinter Review
What's going on here? [not for checkin]
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.
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.
Severity: normal → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
cc ian
Triaging karnaze's bugs.
Assignee: karnaze → kmcclusk
Target Milestone: --- → mozilla1.1
This happens not only with ALT of images. Newline in anchor's TITLE also has small ugly characters. I'll attach screenshot.
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
Closed: 23 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>
*** 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. ***
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
*** 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 :)
Assignee: hyatt → kyle.yuan
CCing alecf, jag, dean to review my patch.
Erh, this doesn't seem like the right solution to me.
Should we be making these multi-line or just converting the linefeeds to spaces? From bug 152243 comment 1: 'According to HTML 4.01, "User agents should interpret attribute values as follows: * Replace character entities with characters, * Ignore line feeds, * Replace each carriage return or tab with a single space."'
Reply to comment #37: As user I'm prefering multiline - with converting the linefeeds to spaces will be very long text unreadable in one single line. Futhermore - it's very easy to write text, which will be wider than any viewport.
I would choose to convert linefeeds to single spaces beacause there is one more side effect. Sample code <input type="text" value="Line breaks here so you will see only one line"> When you place something like that in a page, input will show only "Line breaks" but input also contains the rest -> so the user may submit not what he thinks. Take a look at http://www.netpr.pl - there is a login form, on the right side with such input - user sees only "twój" but input contains "twój login". So people have problems with logging in.
Tooltips has anything to do with values of form widgets???
what do the tooltips for personal toolbar bookmarks use? They show two lines: bookmark title, then bookmark url. Can that feature be applied to "title" tooltips, allowing multi-line tooltips? Regarding the "replace with space" vs "render as newline" issue, I cast my vote in the "replace with space, but allow tooltips to wrap to mulitple lines" camp. -matt
Why does web developer put linefeeds here? Is that just a typo? I don't think so. Run the test case in IE, you can see a two lines tooltip was shown. Reply to comment #41: The tooltip for personal toolbar is a two-lines textbox, because we can't get tooltiptext="Google\n\rhttp://www.google.com" work :(
http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/navigator.xul#285 285 <tooltip id="ptTooltip" noautohide="true" onpopupshowing="return FillInPTTooltip(document.tooltipNode)"> 286 <vbox id="ptTooltipTextBox" flex="1"> 287 <label id="ptTitleText" /> 288 <label id="ptUrlText" /> 289 </vbox> 290 </tooltip> That's what we do for tooltips on bookmarks in the personal toolbar. I'm not sure we can reuse that for title attributes on html elements, but then again I think we should follow the html 4.01 spec and ignore linefeeds and replace carriage returns with a space. Optionally we might choose to wrap long texts instead of cropping them like we do now, though I think title is intended to be a short description, not a screen filling document. Cropping will encourage the former. Kyle: I think you're right that some HTML developers have discovered this bug/feature in IE and are taking advantage of it, but I strongly suspect that there are plenty of pages where the developer hard-wraps the text (by pressing enter) so it fits nicely on his screen and assumes the standard HTML behaviour to apply.
I'm definately for multi-line support in the attribute. Firstly, cause it's the way IE does it. Secondly, cause I'm using that very same feature in my website (which will not work if the browser would ignore linebreaks).
We already crop lengthy titles. Try this: <a href="www.mozilla.org" title="this is a really really really really really really really really really really really really really really really really really really really really really really really really really really really really really really really really really really really really really really really really long title">mozilla.org</a>
See for example comment 13. I strongly doubt the W3 people intended "Extensible Hypertext Markup Language" to be a two-line tooltip with just "Language" appearing on the second line. Jaak: it's cool that your site does what you want it to do in IE, I don't think that's enough of a reason for us to break other sites. Dean: I thought we did, thanks for confirming it.
Multi-line tooltips are extremely useful for creating an online application that needs some short online help. i.e. -- Press this button to submit your changes. Please make sure that you have entered your e-mail address correctly. -- I think we need some way to break tooltips into multiple lines.
Reply comment 37: I doubt where is the spec for that converting. I only see those 3 items at http://www.w3.org/TR/html401/types.html#h-6.2 that is for CDATA. And this link is for title attribute: http://www.w3.org/TR/html401/struct/global.html#h-7.4.3 Does it said we must convert linefeeds?
Some way, maybe. Something as ambiguous (within the context of html at least) as a newline, no. Perhaps "line 1\nline 2" as suggested by Kyle earlier. From a technical point of view, I don't think we should build multiline support into nsTextBoxFrame, we already have a frame that deals with wrapping text, I think we should re-use that instead.
sure, no probs, it is a minor feature anyway. just have to wait until all people are designing websites for IE (:o), so the multi-lined hints in Mozilla could be turned on, without breaking any websites ;)
Kyle: http://www.w3.org/TR/html401/struct/global.html#adef-title says that title is of type text. http://www.w3.org/TR/html401/types.html#type-text says that text is %Text; in the DTD http://www.w3.org/TR/html401/sgml/dtd.html#Text says that %Text; is CDATA. So yeah, it does say that.
"Multi-line tooltips are extremely useful for creating an online application that needs some short online help. i.e. -- Press this button to submit your changes. Please make sure that you have entered your e-mail address correctly." You shouldn't rely on tooltips to convey so much information. If it's not obvious from your form what something does, the form should have the help text directly on it.
I saw that. jag and dean, you are right.
"You shouldn't rely on tooltips to convey so much information. If it's not obvious from your form what something does, the form should have the help text directly on it." It was just an example. I use tooltips on my personal webpage in a table if recent visitors. It's just a small table so I cut off the text of the IP address/hostname if it's too long. Hover the mouse over it and the full name gets displayed along with the referrer (referrer on a separate line). Displaying the information every time would hog up way too space, and clicking on a link to go somewhere else to display those two lines would be overkill. The tooltip however, works great for this. I'm just saying that tooltips should have multiple lines. If the title tag won't support it then there should be an alternate way of doing it. Unless you can think of a reason tooltips ought not be able to have multiple lines?
"Unless you can think of a reason tooltips ought not be able to have multiple lines?" The standard says they shouldn't. See comment 48 and 51. Important quotes from the first link in comment 48 is "Ignore line feeds" and "Replace each carriage return or tab with a single space".
For an example, i want to use title for IMG object. In the title there will be text like this: " Name: IMG_NAME.jpg Date: 2002-07-18 Scene: World Cup match Poland-Brasil Access: xrwr-r- Author: Jon Smith " It'd be very usefull for me in this and many other situation. Tooltip is very, very helpfull in interface. It doesn't grab space, its easy to implement... Why not?
nominating for nsbeta1, because there are 14 duplicates and so many complains. We must do something for this, either fix it or mark won't fix :(
Keywords: nsbeta1
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.
Attachment #91779 - Attachment is obsolete: true
=> component owner
Assignee: kyle.yuan → jaggernaut
I'm all in favor of doing the right (read: standards-compliant) thing and duping this against 47078.
*** Bug 172534 has been marked as a duplicate of this bug. ***
Ack. I should have cc'd myself to this bug a while ago. There's a fundamental confusion here as to what this bug is about: 1) HTML 4.01 requiring newlines to be converted to whitespace in attributes (bug 470478). This is a valid bug, BUT it only applies to newlines present as such in the source. If you place the entities &#10;&#13; in the text of a title attribute, this SHOULD produce a linebreak. This is the ONLY way to produce a linebreak in attribute text. So I would advise changing the binding and allowing multi-line tooltips as standards-correct. (We could still decide not to respect line breaks when they appear within a tooltip box, just as we don't let them break text in an HTML page except in <pre>, but that would be an internal decision regarding tooltip rendering and have nothing to do with the HTML 4.01 spec.)
I totally agree with Chris. See comment 37, "Replace each carriage return or tab with a single space.", What does this mean? IMO, It means that we should convert the "invisible* carriage return/tab to a single space, like this: "fooA fooB fooC fooD" => "fooA fooB fooC fooD" But for the soft coded |\n\r|, it should be kept there to satisfy the webdesigner's original intention.
*** Bug 173025 has been marked as a duplicate of this bug. ***
*** Bug 178942 has been marked as a duplicate of this bug. ***
nsbeta1+/adt3 per the nav triage team.
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt3]
*** Bug 180279 has been marked as a duplicate of this bug. ***
*** Bug 182471 has been marked as a duplicate of this bug. ***
*** Bug 111609 has been marked as a duplicate of this bug. ***
*** Bug 184700 has been marked as a duplicate of this bug. ***
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) :-)
Nav triage team: nsbeta1-
Keywords: nsbeta1+ → nsbeta1-
Whiteboard: [adt3]
I totally agree with Brian's comment 71. Explicit newlines (entities) should be honored, "implicit" newlines converted to spaces. Bug 47078 should deal with the conversion, and in this bug, the issue of making the explicit newlines work should be addressed. It seems that this bug's dependence is the other way around: this _depends_ on bug 47078, and not vice versa. BTW, see also bug 45375 - "tooltips should wrap".
Here is another page regarding tooltips: http://www.petesguide.com/WebStandards/tests/tooltips.html
*** Bug 45375 has been marked as a duplicate of this bug. ***
I too agree with Brian's <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=67127#c71">comment 71</a>. We need a multi line comment and the way of IE is good for us. I think that Mozilla could go the some way. IE is less standard browser but is the more used due to Microsoft bad W3 compliant too. So if Mozilla would replace IE must do what IE do. For now our client use IE. I hope they will use Mozilla soon ;)
*** Bug 195552 has been marked as a duplicate of this bug. ***
*** Bug 195913 has been marked as a duplicate of this bug. ***
*** Bug 198197 has been marked as a duplicate of this bug. ***
*** Bug 198725 has been marked as a duplicate of this bug. ***
*** Bug 202178 has been marked as a duplicate of this bug. ***
If no one is planning to work on it, you can assign it to me.
finally. Thank you Brian for interesting.
*** Bug 203639 has been marked as a duplicate of this bug. ***
*** Bug 204166 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.1alpha → ---
*** Bug 205128 has been marked as a duplicate of this bug. ***
*** Bug 212973 has been marked as a duplicate of this bug. ***
Attached patch Lame patch (obsolete) — — Splinter Review
* I don't understand why I have to set the height and width manually * I can't get this to work in XBL, only in XUL as shown :-(
Comment on attachment 129857 [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 :)
Attached patch Newline-only patch (obsolete) — — Splinter Review
This version makes all tooltips multiline by splitting on newlines but it doesn't handle tabs.
Neil: why not do the xbl in the setter for the label property?
I agree with comment 71. So with character entities being turned into their character equivalents, at the DOM end we'll see CRLFs and TABs, right? Then Neil's patch is a good start (if not the answer), and until bug 47078 is fixed, we'll get the complete IE behaviour (modulo "bugs") for free. Once bug 47078 is fixed though, CRLFs in the HTML will become spaces and some of these testcases/sites will stop working as expected (note that IMHO the expectation is wrong). Do we want to introduce this now and "break" things later, or should we wait till bug 47078 is fixed?
No longer blocks: 47078
Depends on: 47078
jag: which way do you like better, the pre css one or the splitting version?
I am sorry, but as I discovered that this Bug, Misbehaviour or "not running along with IE" is a open bug since 2001/01, I am quite disapointed about Mozilla. So many discussions and no solution to a simple problem, which affects a lot of sites and make them hard to use/read, is undescribable situation. Could some please get rid of this Bug... PRETTY PLEASE?
Re Comment #95 (and anymore potential Me To's) At the top of this bug report, you can see that a patch was attached by Neil on 15/8 (15 August) and is undergoing the official Mozilla review process. Yes, this bug has been around for a while, but I notice that the patch is from someone who is "officially" not part of Mozilla, but is a programmer somewhere who decided to have a go at fixing the problem. While I haven't encountered this bug myself, I thank Neil for his unpaid work on fixing it for all of us. NEIL: Shouldn't this bug be Assigned to you?
There is no reason for the bug to be assigned to Neil unless he wants it and Jag wants to assign it to him. Assigning it to him wouldn't make much of a difference.
How about shutting up and letting people fix bugs quietly? What a novelty...
This semi works (popup.xml): <binding id="tooltip" extends="chrome://global/content/bindings/popup.xml#popup"> <content> - <children> - <xul:label class="tooltip-label" xbl:inherits="value=label,crop" crop="right" flex="1"/> - </children> + <xul:label style="white-space: pre;" class="tooltip-label" xbl:inherits="xbl:text=label,crop" crop="right" flex="1"> </xul:label> + <children /> Just the height/width is still messed up, for which Neil has a (albeit somewhat ugly) workaround. Not sure why the original code had the anon content inside the <children> tag though.
What Doron Rosenberg is saying (in a not so polite manner - though I think it wasn't meant to be rude, just humerous ;-) ) is that complaining in a bug will not make it fixed any faster when there is already a patch available.
re Comment #98. You're right, I should just accept patches quietly, and be just as quiet about any new bugs. I shouldn't thank people for their work as I must be quiet. I shouldn't bother doing any testing as it achieves nothing as I must be quiet. I should not file a Bugzilla bug regarding a problem which I noticed with this bug report as I must be quiet.
You don't have to be quiet. Its just since this bug is currently being reviewed, etc, so it can't move any faster than it is. We have a limited number of reviewers. By all means, you can thank people, but also its probably better to do that through private email unless you want to thank everyone that worked on the bug. At least half the patches or more are worked on people that aren't official members of the foundation. I think doron was more responding to this: > Could some please get rid of this Bug... PRETTY PLEASE? You must realize we have had some bugs "spammed out" by people complaining, etc and not really adding any implementation details, etc. Bugzilla is more for developer conversations than for advocacy, etc. That's what votes are for (although we should have a way for people to provide info on why they voted a certain way as they vote, and there is a bug for that). doron was just trying to prevent this bug from being off-topic. There isn't any reason you should take it personally. This stuff happens all the time, and some developers have less patience than others. I should have emailed privately to you, but I wanted to also have it here for the benefit of other people who might have been offended.
hyatt on irc suggested (to fix the sizing issue) to not use xbl:text but just change the textnode myself (or so I understood from him) - now the tooltip doesn't even show up at all.
bryner, any idea why we need to reset the height to the boxObject height?
What is the height before you do that? 0?
Its the height of one character (original height I believe)
*** Bug 218873 has been marked as a duplicate of this bug. ***
About duplicate Bug 218873. i do not get black bars as shown in a screen shot for this bug - i get squares. Though this may just be due to system font etc. Just thought might be worht mentioning. P.s. Sorry about duplicate - but i couldn't search for black bars/lines if i didn't get em :)
Comment on attachment 129862 [details] [diff] [review] Newline-only patch I prefer this approach.
Attachment #129862 - Flags: superreview+
Blocks: majorbugs
Interested developers please have a look at http://forums.mozillazine.org/viewtopic.php?t=38949
Taking
Assignee: jag → bugzilla
Accepting
Status: NEW → ASSIGNED
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
Attachment #129857 - Attachment is obsolete: true
Attachment #129862 - Attachment is obsolete: true
Attachment #130594 - Attachment is obsolete: true
Attachment #136944 - Flags: review?(neil.parkwaycc.co.uk)
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 on attachment 136944 [details] [diff] [review] New Patch v0.1 - based on newline-only patch r=jag
Attachment #136944 - Flags: review?(jag) → review+
Comment on attachment 136944 [details] [diff] [review] New Patch v0.1 - based on newline-only patch r=jag
Attachment #136944 - Flags: superreview?(bz-vacation)
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+
Attachment #136944 - Flags: approval1.6b?
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
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-
Re comment#120 erm good point don't why I didn't pick that up Re comment#121 ok I'll spin a patch that uses \uFFFD instead of "?" it was my understanding that we did actually want to convert the literal "\n" characters but I can take that out.
My understanding was that "&#10;" should be converted into \n and "&#13;" into \r. (See comment #62.)
Attached patch New patch 0.1.5 (obsolete) — — Splinter Review
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.
URL: http://conferences.oreilly.com/oscon2... → http://www.petesguide.com/WebStandard...
Zbigniew: \n and \r are line-breaks for C printf and scanf statements, along with perl. In C++, you use character-code entities for line-breaks, read (from the spec): * Replace character entities with characters, * Ignore line feeds, * Replace each carriage return or tab with a single space. That is pretty clear. \n is simply text, and shouldn't be interpreted as anything else, since \ is not an escape character in CDATA. Line feeds appear as spaces, and only thing that gets interpreted are character entities, like &gt; Therefore, we should use character entities to insert line-breaks in titletips, and if IE does anything extra (like interpret \n), they are doing it wrong. <span title="yes o">test</span> According to the spec, line-breaks in the HTML file itself appear as whitespace, so that should appear as "yes o" all on one line.
From my testing <span title="yes&#10;no">test</span> seems to get interpreted the same ways as <span title="yes no">test</span> Which is where bug 47078 comes in I presume?
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.)
I agree with both Brian and Zack. See previous comments in this thread. Reading Hixie's comment 121, I now disagree with my comment 49, \n should just be displayed as the literal "\n", not as a newline. See comment 93 for what I think should happen, and has been mentioned elsewhere, any newline chars should be treated as whitespace (currently blocked by bug 47078), the entity &#xA; (or perhaps all of &#xA;, &#xD; and &#xD;&#xA;) should be turned into a newline and displayed as such in our tooltips.
Comment on attachment 137054 [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).
Attached patch New patch 0.1.6 (obsolete) — — Splinter Review
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
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>
I don't understand why tabs are failing. I think we should remove the tab- specific code here (it doesn't do alignment of tabs, e.g.) and instead file a bug on getting tabs to work in this case (preferably with a small testcase). Similarly, if we are trying to emulate CSS rules here, we should not be looking for U+000D at all, and should only be splitting on U+000A. I don't see how we could get a U+000D in there anyway unless the author is being silly enough to explicitly say title="foo &#13; bar" in which case he deserves what he gets. Any particular reason we're not just rendering this using -moz-pre-wrap? That would get around most of these problems as far as I can tell (wouldn't be any need to special case any of this).
> One of the questions is should we using \uFFFD if JS/DOM is only UTF-16, if not > then should we go back to using "?" I don't understand this, by the way. What has UTF-16ness got to do with that?
I'll try to get my brain in better order today - I realised almost as soon as I hit the commit button I'd got myself completely confused on the UTF-16 issue. Anyway, I've already been testing the use of style="white-space: -moz-pre-wrap;" within popup.xml and it seems to be completely ignored. Neil also suggested maybe trying max-width too, but again it has on impact. I tested both with vbox and label, so not sure what is going on with that yet. As mentioned in comment #132 older MACs use &#13; but I expect those MACs don't run OS X so do we need to support that use? Can someone confirm? To me it looks like we have a couple of choices: a) Put in a temporary fix to address the issue of this bug within popup.xml and investigate a more permament fix b) Forget the temporary fix and just concentrate on the permament fix The other question is why are control characters other than LF making it this far - this, I suspect, should be part of the permament fix.
> As mentioned in comment #132 older MACs use &#13; No, they don't (unless I'm very much mistaken). They might use U+000D (literal character decimal 13), but they don't use the escape "&#13;", which is all that should be creating a newline. Looks to me like we should file bugs on the parser and on the style system to get the input parsed right (U+000A should become a space and "&#10;" or "&#xA;" should become a newline) and -moz-pre-wrap rendered right respectively, and make this bug dependent on them.
Attachment #129857 - Flags: superreview?(jag)
Attachment #129857 - Flags: review?(doronr)
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?
Bugzilla Bug 45376 You can make a bug depend on itself. - Verified Fixed This bug really has a patch that provides a fix for that? impressive.
I think he meant bug 45375, which is related and does currently have 88 votes.
In the meantime, it might be reasonable to check in the patch that would be the correct fix once those parser bugs were fixed. This would have the advantage that it gets rid of the unsightly black boxes and that it gives authors a way (avoid literal newlines in title attributes; use &#x0A;) to get what they want both in current Mozilla and in a correct Mozilla. -moz-pre-wrap sounds like a more complex issue since one would need to decide when to wrap -- I think it's OK to fix this bug without wrapping, for now. There's no need to fix every problem related to tooltips in a single checkin.
Sorry for the typo, yes Michael I mean bug 45375 (thanks timeless for spamming this bug with your cynism, unlike Michaels response yours adds nothing constructive to this bug). David I agree, but is there anything that would speak against using the fix for the wrapping issue that exists in this patch at least as a temporary solution until some alternative method gets worked out?
> since one would need to decide when to wrap I'd rather we left wrapping up to the web authors on tooltips (talking from the perspective of a web author this time), because we might cause a wrap when they don't want it. It would be nice in some cases, though, for really long tooltips if we could handle it for them and create the tooltip with a width that was good for their machine. I don't know how we could accomodate both possibilities, though.
How about adding a hidden pref, so users can change the wrap-length, if they want to? Set this to 64 (or a bit higher?) as a default should be more then ok. Although I doubt, that many users change the default value it would be nice if people could. It's better, than hardcoding it and better, than an endless discussion, how long that should be at the end.
Would relating the width of the tooltip to the width of the window it is being generated from be a good idea? Do we want to, temporarily, strip out other control characters that will generate black bars?
Summary: Newline in tooltips converted to black bars → Newline in tooltips (title attribute) converted to black bars
Depends on: 228099
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.
Attachment #136944 - Attachment is obsolete: true
Depends on: 228673
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
From comment #151: > Would relating the width of the tooltip to the width of the window > it is being generated from be a good idea? This looks like a good idea to me, unless it's easy to solve.
*** Bug 238889 has been marked as a duplicate of this bug. ***
*** Bug 152157 has been marked as a duplicate of this bug. ***
*** Bug 244185 has been marked as a duplicate of this bug. ***
Flags: blocking1.7+
standsongrace: Please do not add blocking flags; that's for drivers.
Flags: blocking1.7+
I just tested using the &#10; character in my title attribute for a span in both mozilla and firefox, and they both display a small black vertical bar in win2k, and in linux I get a junk character. Evidently this isn't being handled correctly still.
*** Bug 248168 has been marked as a duplicate of this bug. ***
It has been three and a half years since the discovery of this small, yet annoying bug and it is still there :/ I feel like I'm using software from the 'one and only right company'...
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-
If we can make progress on getting this reviewed and ready for check in we could consider taking it on the aviary branch. renominate after review. thanks
*** Bug 113595 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.0
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.
No longer depends on: 47078, 228099
Flags: blocking1.8a3? → blocking1.8a3-
Attachment #137769 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #137769 - Flags: review?(neil.parkwaycc.co.uk)
*** Bug 253899 has been marked as a duplicate of this bug. ***
Is there any chance that we could temporarily apply a _partial_ patch to this? That is, could we create a patch that would eliminate the actual problem (strange characters in the tooltip when there just happens to be a line break in the HTML) without worrying about adding these new features (change the underlying implementation to allow multi-line tooltips)? My impression is that the difficulties with the current patch are only on the "feature enhancement" side of the issue.
*** Bug 264570 has been marked as a duplicate of this bug. ***
Is it really necessary to replace control characters with U+FFFD or "?" here? Why assume the user's font doesn't have a meaningful glyph for these characters? If that substitution is normal/desirable, why isn't it happening in the rendering code instead? If the goal is simply to avoid the "black bars" and replace them with the Unicode REPLACEMENT CHARACTER instead, this seems misguided. If authors have no business specifying control characters in their text, it shouldn't matter if the font's glyph for that character is a square/black bar. The real problem here is that authors felt they *do* have business putting newlines in their "title" attributes. I'm not sure a blanket control character substitution is appropriate as it doesn't appear to be fixing the (right?) problem.
Just seen it with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a5) Gecko/20041020 Firefox/0.9.1+ the newlines in source code are displayed by some block graphics charcters.
*** Bug 266448 has been marked as a duplicate of this bug. ***
Always here in Firefox 1.0 final ...
*** Bug 269495 has been marked as a duplicate of this bug. ***
*** Bug 272573 has been marked as a duplicate of this bug. ***
*** Bug 273144 has been marked as a duplicate of this bug. ***
It's not so much a case of authors putting significant newlines in their titles as it is a case of insignificant whitespace (as is allowed all through HTML / XHTML) being contained within titles. Consider an acronym tag like: <acronym title="This Is A Longer Than Average Acronym Being Used As An Example">TIALTAABUAAE</acronym>. Theoretically the XHTML author could break this beast up pretty much anywhere and still have it display the same thing (and in fact programs like Tidy will happily break it up to keep individual line lengths under control) and while most rendering engines will do the right thing, Gecko will display black bars.
. o O (looking at the date this bug was reported I feel this debate is nothing but academical :o)
This is considered a valid bug, or it would be marked invalid. It's just not a high priority bug, and the solution is not so clear from the standards. There is a patch if anyone would like to dust it off. Wrapping the title is not a good idea because people might want to show a pre-formatted title, like ASCII art or something less silly :-)
*** Bug 273768 has been marked as a duplicate of this bug. ***
*** Bug 273854 has been marked as a duplicate of this bug. ***
*** Bug 275450 has been marked as a duplicate of this bug. ***
(In reply to comment #177) > Wrapping the title is not a good idea because people might want to show a > pre-formatted title, like ASCII art or something less silly :-) I don't think that usage (at least with carriage returns and/or linefeeds) is allowed in standard HTML. The spec says that: '''For all HTML elements except PRE, sequences of white space separate "words" (we use the term "word" here to mean "sequences of non-white space characters"). When formatting text, user agents should identify these words and lay them out according to the conventions of the particular written language (script) and target medium.''' and goes on further to say that: '''In particular, user agents should collapse input white space sequences when producing output inter- word space. This can and should be done even in the absence of language information (from the lang attribute, the HTTP "Content-Language" header field (see [RFC2616], section 14.12), user agent settings, etc.).''' It identifies characters: space (&#x0020;), tab (&#x0009;), form feed (&#x000C;), zero-width space (&#x200B;), carriage return (&#x000D;), and line feed (&#x000A;) as white space characters. No exception is made for the title attribute. This is why standard (and extremely widespread) tools like Tidy freely break up long titles across multiple lines. Authors expecting to preformat title attributes with spaces, tabs, form feeds, zero-width spaces, carriage returns, and line feeds are expecting a behavior that's seemingly at odds with the specification. However, the spec also states that: '''This specification does not indicate the behavior, rendering or otherwise, of space characters other than those explicitly identified here as white space characters.''' so preformatting with other white space characters (e.g., next lines (&#x0085;), line separators (&#x2028;), paragraph separators (&#x2029;), etc.) is allowed but is still an extension that HTML authors shouldn't automatically expect to work everywhere. We shouldn't be holding up a fix for something that is an obvious, blatant, embarrassing bug that even shows its bad behavior on the W3C site because some Web page authors (I believe a minority) are currently relying on unspecified behaviors. I'm all in favor of adding support for preformatted titles using next lines, etc., but it should be done at a later date and probably via a separate feature request. The bug should be fixed first, and the enhancement added later.
Feneric, it looks like you're confusing characters and character entities. See comment 131 for what everyone seems to agree is the correct behaviour. It's just a matter of getting the code patched to do that!
First, it's only just hit me that this bug was first reported in the context of ALT text for images, but the current summary and the existing patches for the problem apply only to tooltips. Given that newlines in ALT text are still handled improperly (just tested with Firefox 1.0 on Win98), is there any bug still dealing with that (and with newlines handled improperly in other attributes), or should a new one be filed? It seems like many of the ideas being implemented here should apply generally to all attributes (though bug 228099 comment 7 points out why quirks mode should avoid these replacements for the "value" attribute, at least). And second, in reply to comment #182: > Feneric, it looks like you're confusing characters and character entities. See > comment 131 for what everyone seems to agree is the correct behaviour. It's > just a matter of getting the code patched to do that! It looks to me like Feneric's point is essentially the same one that I made in comment 166. This bug started life as a request to honor the HTML specification by treating whitespace as whitespace rather than changing some of it into visible characters. But at some point, it evolved into a worthy but rather different enhancement request to enable pre-formatted (multi-line) tooltips using explicit character entities. I agree that this enhancement is a valid and useful reading of the specification! But I'm not convinced that the two issues are related, either conceptually or in the code. As I understand it, solving the original problem should just be a matter of replacing every block of whitespace in a title attribute with a single space ("s/\w+/ /g", I think), and there's probably already code somewhere that does that ("white-space: normal" in CSS, for instance). Even if it's not quite that easy, the original problem can't possibly have anything to do with the current blocking bug 228673 (which wouldn't arise here at all without patch v0.4's change to browser.js that enables multi-line tooltips). In short, it looks to me like the original bug could probably be fixed without too much trouble by those who know the code. (Please correct me if that's wrong!) But instead, that fix is being incorporated into a complicated enhancement with a fairly low apparent priority. So why not spin off the enhancement into its own bug (or if it's easier at this point, create a new bug for the original issue and relabel this one), and in the meantime check in a fix for the original problem?
FWIW that latest patch is still valid, just the line numbers have changed. I tried it and it worked fine, except for a problem I noticed with 'normal' tooltips. If there was no newline in the title attribute, the tooltip box was twice as high as it needed to be. Something like this would fix it: if (t.search(/\n/) >= 0) { tipNode.setAttribute("height", tipNode.boxObject.height); } else { tipNode.setAttribute("height", tipNode.boxObject.height - 16); } I'm sure the height of the tooltip (16 on my PC) is stored somewhere else and is not a fixed value. And although I agree with much of comment 183 that this bug has gotten off track, it's only a 2 or 3 line fix that would solve the original problem! Why doesn't someone do it! (I've got no idea how to make one of those diff files, otherwise I'd give it a go myself.)
*** Bug 277528 has been marked as a duplicate of this bug. ***
*** Bug 278848 has been marked as a duplicate of this bug. ***
*** Bug 278972 has been marked as a duplicate of this bug. ***
*** Bug 280167 has been marked as a duplicate of this bug. ***
A testcase for acronym tooltip with \n(LF) and \t charcters inside.
*** Bug 287094 has been marked as a duplicate of this bug. ***
*** Bug 216592 has been marked as a duplicate of this bug. ***
*** Bug 67127 has been deleted, removed due inactivity. *** /Sarcasm End Since more than 4 years a bitterly fight goes over an tiny problem. But this problem got some powder in itself and nevertheless it threatens to split a religion and couse civil war, disaster and a lot of death. Why? Cause it means, W3C seen as pontifex of WWW is unfailable and not questionable. Or should the masses get their rights and tell and use learned methods for themselfs, without considering the wishes of the wise and lonely top? I estimate we have an answer to a problem in 5 more years, which solved itself due time automatically. And everybody, who dont wont to wait this long period of war, I tell: http://piro.sakura.ne.jp/xul/_popupalt.html.en#download Maybe, this brave act of an civillian will help us to lead the pontifex W3C to a better way of understanding of their people. (Well, me personaly think, nope, but we must provide a positive way for our W3C.) PS: Couldnt stop me from writing this, since I look up this matter for a long time now. *Flame start here*
*snort*hahahahaha*snort* Sorry, you commented in the wrong bug, this is not the alt-as-tooltip bug.
Yeah, but Piro's extension fixes this bug too. Actually when this bug started Moz could still display ALT text as evidenced by the first test case which is demonstrating the "black bars". Black bars that are not even visible now because the ALT text is not displayed. Perhaps that makes this bug "invalid"
(In reply to comment #194) > Yeah, but Piro's extension fixes this bug too. Actually when this bug started > Moz could still display ALT text as evidenced by the first test case which is > demonstrating the "black bars". Black bars that are not even visible now > because the ALT text is not displayed. I don't follow you. Mozilla _does_ display ALT text, and always(?) has: when the image is unavailable or when it hasn't loaded yet. That's what ALT text is for: an alternative way of conveying image content. (And that's pretty clearly the context of the original report, which mentions that the display of the text is different depending on whether the image is still trying to load or whether Mozilla has given up.) As I said in comment #183, I've tested this myself with Firefox 1.0 and the ALT text bug is still there (as is the tooltip problem, of course).
I've just tried. Firefox doesn't display the alt text when the images are not displayed.
(In reply to comment #196) > I've just tried. Firefox doesn't display the alt text when the images are not > displayed. Did you try the original reporter's testcase? (That is, create a local file whose contents are the HTML snippet he gave: the linked testcase URL for the bug was apparently changed to a tooltip example at some point.) I've got that case open in another tab right now (Firefox 1.0.1 on OS X), and the ALT text is shown, strange box characters and all.
OK, Firefox displays the alt text only when the images are shown (I don't think this condition is a good idea, since the goal of the alt text is to give some information when the image is not visible, but well...).
*** Bug 292990 has been marked as a duplicate of this bug. ***
XML 1.0 spec., section 3.3.3 Attribute-Value Normalization sais: For a white space character (#x20, #xD, #xA, #x9), append a space character (#x20) to the normalized value. So I think that no new line in attribute can be rendered (at least in XHTML).
I´m not sure I see the reason for this year-long discussion - the specs state clearly that newlines and similar are to be replaced with white-space. The reason probably being that such characters aren´t valid in all encodings(Win/Unix for example). Nowhere it says that a browser mustn´t break long lines - shouldn´t a tooltip be handled the same way regular HTML is? I.e. if it´s too long for one line - break it. There is no way an author can know in advance how many characters he can use - so breaking the line at window-end seems to be the only reasonable solution - and it´s something the UA has to do, not the web-author. (Sorry if I repeated what someone else said - I didn´t read the entire thread, I skipped portions.)
(In reply to comment #201) > I´m not sure I see the reason for this year-long discussion - the specs state > clearly that newlines and similar are to be replaced with white-space. The > reason probably being that such characters aren´t valid in all > encodings(Win/Unix for example). > > Nowhere it says that a browser mustn´t break long lines - shouldn´t a tooltip be > handled the same way regular HTML is? I.e. if it´s too long for one line - break it. > There is no way an author can know in advance how many characters he can use - > so breaking the line at window-end seems to be the only reasonable solution - > and it´s something the UA has to do, not the web-author. > (Sorry if I repeated what someone else said - I didn´t read the entire thread, I > skipped portions.) I'd suggest to direct your attention to comment #62, which BTW perfectly describes my own opinion as I don't like idea of violating the standards yet I'm sure web-authors definetely should have the possibility of breaking line at a particular position.
No longer blocks: majorbugs
2 Questions: 1. What is 'Patch v0.4 based on Doron's patch' exactly doing? It it doing, what has been suggested in Comment #62 and/or Comment #71? 2. Why wasn't review or superreview being requested for this patch?
*** Bug 296920 has been marked as a duplicate of this bug. ***
(In reply to comment #203) > 2 Questions: > 1. What is 'Patch v0.4 based on Doron's patch' exactly doing? It it doing, what > has been suggested in Comment #62 and/or Comment #71? > 2. Why wasn't review or superreview being requested for this patch? The answer to 2 is that either it doesn't work, or isn't acceptable for some reason. I don't recall the details, but there are some subtleties here. If I remember correctly, Neil rejected the patch on IRC. Explicitly messing with the boxObject.height is almost certainly not the correct solution.
For the record, Ubuntu bug http://bugzilla.ubuntu.com/show_bug.cgi?id=12998 is the same bug as this one, with another test case, another use case, and another sarchastic comment (comment #3)
*** Bug 313154 has been marked as a duplicate of this bug. ***
*** Bug 321593 has been marked as a duplicate of this bug. ***
Depends on: 322270
As I suggested in comment 183, I have just spun off the originally reported issue in this bug (regarding black boxes in images' ALT text) into bug 322413. Both that new bug and this one are now set to depend on bug 322270, which I recently filed to deal with whitespace in attributes generally. After those changes, it might be reasonable to make this bug's summary reflect its current focus: enabling multi-line tooltips. (But it should probably still mention the black bar problem, too, to help people find the problem.) I'll leave it to the bug owner to make that decision.
This bug is still open. Cmon guys - lets fix it before its 6th anniversary ;-)
(In reply to comment #210) > This bug is still open. Cmon guys - lets fix it before its 6th anniversary ;-) > You got a patch?
(In reply to comment #210) > This bug is still open. Cmon guys - lets fix it before its 6th anniversary ;-) To summarize the current status of this bug: The "black bars" problem will be (essentially) fixed as soon as bug 322270 is fixed. That bug's owner has set a target milestone of mozilla1.9alpha, which I believe means "in time for Firefox 3". (It sounds like there may be some fairly low-level changes involved, which may be more than the 1.8 branch is expected to handle at this point.) The "multi-line tooltips" enhancement that's also been discussed in this bug is a somewhat independent issue. If bug 322270 is fixed in a way that allows the desired behavior in comment 131, then the parsed value of the "title" attribute will include actual line feed characters for each "&#10;" in the source. We'll then want the tooltips themselves to behave something like "white-space: -moz-pre-wrap" as suggested in comment 140 (though wrapping tooltips may deserve a separate bug). As I see it, the main danger in implementing the eventual fix for multi-line tooltips before bug 322270 is fixed is that page authors might mistakenly think that we were endorsing the standards-violating MSIE behavior (and get upset when the eventual fix limiting them to the method in comment 131 landed). But if anyone can make a patch for this work, we'd all love to see it.
Extension Popup ALT Attribute fixes this bug for me and enables multi-line tooltip. I didn't had any strange behavior with it, so it maybe can help with fixing those bugs.
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 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)
Attachment #210603 - Flags: superreview?(alecf)
*** Bug 326049 has been marked as a duplicate of this bug. ***
Attachment #210603 - Flags: superreview?(alecf) → superreview+
Attachment #210603 - Flags: review?(jag) → review?(bryner)
Attachment #210603 - Flags: review?(bryner) → review+
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)
Whiteboard: [checkin needed]
Attachment #210603 - Flags: approval-branch-1.8.1?(bryner) → approval-branch-1.8.1+
*** 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]
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. ***
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.
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
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
Closed: 23 years ago → 18 years ago
Resolution: --- → FIXED
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.)
Component: XP Apps: GUI Features → UI Design
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.
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
See Also: → https://launchpad.net/bugs/19250
Restrict Comments: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: