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)
SeaMonkey
UI Design
Tracking
(Not tracked)
VERIFIED
FIXED
seamonkey1.1beta
People
(Reporter: mpercy, Assigned: csthomas)
References
()
Details
(Keywords: compat, fixed-seamonkey1.1b, testcase)
Attachments
(7 files, 7 obsolete files)
9.77 KB,
image/jpeg
|
Details | |
238 bytes,
text/html
|
Details | |
2.91 KB,
text/html
|
Details | |
2.00 KB,
patch
|
Details | Diff | Splinter Review | |
367 bytes,
text/html
|
Details | |
742 bytes,
patch
|
bryner
:
review+
dbaron
:
superreview+
bryner
:
approval-branch-1.8.1+
|
Details | Diff | Splinter Review |
2.65 KB,
patch
|
Details | Diff | Splinter Review |
See description and URL: pretty self-explanitory. Note: if the above URL loads quickly and you do not see the ALT text, put this into a file and view it: -- <HTML><BODY><IMG width="300" height="100" src="http://blah.com/tmp/nowhere.gif" ALT="See the Black Square(s)?"></BODY></HTML> -- At the testcase URL, IE5 renders the top ALT text as: O'Reilly Open Source Software Convention Moz renders it as: O'Reilly Open Source Software |Convention (with the | representing a black square) This is on WinNT4 SP6. Interestingly enough, when the image times out the display of the ALT text is changed to render as inline HTML would. I'm not sure what the spec says about this, but IE5's rendering makes more sense to me than the "inline HTML" way, but either is better than this. Seeing this in Build 2001-01-30-04-Mtrunk on NT4.
Comment 1•24 years ago
|
||
no black square on linux build 2001-01-29-08. Could this be windows-only?
Reporter | ||
Comment 2•24 years ago
|
||
I am seeing this again with today's builds, both on my NT4 workstation and my W2k laptop. Build 2001-01-31-09-Mtrunk/mozilla-win32-installer.exe
Comment 3•24 years ago
|
||
Confirmed Platform: PC OS: Windows 98 Mozilla Build: 2001012904 Marking NEW.
Severity: normal → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 4•23 years ago
|
||
cc ian
Triaging karnaze's bugs.
Assignee: karnaze → kmcclusk
Target Milestone: --- → mozilla1.1
Comment 6•23 years ago
|
||
This happens not only with ALT of images. Newline in anchor's TITLE also has small ugly characters. I'll attach screenshot.
Comment 7•23 years ago
|
||
Comment 8•23 years ago
|
||
See also bug 47078, Newlines are not converted to whitespace in attributes.
Comment 9•23 years ago
|
||
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
Comment 10•23 years ago
|
||
Reopening, this bug is still valid for quirks mode.
Comment 11•23 years ago
|
||
*** Bug 98120 has been marked as a duplicate of this bug. ***
Comment 12•23 years ago
|
||
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
Comment 13•23 years ago
|
||
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 4 as an XML 1.0 application, and three <abbr title="Document Type Definition">DTDs</abbr>
Comment 14•23 years ago
|
||
*** Bug 101151 has been marked as a duplicate of this bug. ***
Comment 15•23 years ago
|
||
This also happens on build 2001092205 Mac OS X 10.0.4 in title attributes in <a> elements. Sorry about filing the duplicate.
Comment 16•23 years ago
|
||
*** Bug 49614 has been marked as a duplicate of this bug. ***
Comment 17•23 years ago
|
||
Comment 18•23 years ago
|
||
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.
Comment 19•23 years ago
|
||
Reassigning to XPTOOLKIT
Assignee: kmcclusk → hyatt
Status: REOPENED → NEW
Component: Layout → XP Toolkit/Widgets
QA Contact: petersen → jrgm
Comment 20•23 years ago
|
||
*** Bug 113796 has been marked as a duplicate of this bug. ***
Comment 21•23 years ago
|
||
*** Bug 119913 has been marked as a duplicate of this bug. ***
Comment 22•23 years ago
|
||
*** Bug 122109 has been marked as a duplicate of this bug. ***
Comment 23•23 years ago
|
||
*** Bug 122210 has been marked as a duplicate of this bug. ***
Comment 24•22 years ago
|
||
*** Bug 132252 has been marked as a duplicate of this bug. ***
Comment 25•22 years ago
|
||
*** Bug 140685 has been marked as a duplicate of this bug. ***
Comment 26•22 years ago
|
||
*** Bug 144068 has been marked as a duplicate of this bug. ***
Comment 27•22 years ago
|
||
*** Bug 144798 has been marked as a duplicate of this bug. ***
*** Bug 152243 has been marked as a duplicate of this bug. ***
Comment 29•22 years ago
|
||
*** Bug 154160 has been marked as a duplicate of this bug. ***
Comment 30•22 years ago
|
||
*** Bug 156133 has been marked as a duplicate of this bug. ***
Comment 31•22 years ago
|
||
It's because our nsTextBoxFrame doesn't support multi-line text.
Comment 32•22 years ago
|
||
so is there already someone creating another nsTextBoxFrame that supports multi-line text? :)
Comment 34•22 years ago
|
||
Comment 35•22 years ago
|
||
CCing alecf, jag, dean to review my patch.
Comment 36•22 years ago
|
||
Erh, this doesn't seem like the right solution to me.
Comment 37•22 years ago
|
||
Should we be making these multi-line or just converting the linefeeds to spaces? From bug 152243 comment 1: 'According to HTML 4.01, "User agents should interpret attribute values as follows: * Replace character entities with characters, * Ignore line feeds, * Replace each carriage return or tab with a single space."'
Comment 38•22 years ago
|
||
Reply to comment #37: As user I'm prefering multiline - with converting the linefeeds to spaces will be very long text unreadable in one single line. Futhermore - it's very easy to write text, which will be wider than any viewport.
Comment 39•22 years ago
|
||
I would choose to convert linefeeds to single spaces beacause there is one more side effect. Sample code <input type="text" value="Line breaks here so you will see only one line"> When you place something like that in a page, input will show only "Line breaks" but input also contains the rest -> so the user may submit not what he thinks. Take a look at http://www.netpr.pl - there is a login form, on the right side with such input - user sees only "twój" but input contains "twój login". So people have problems with logging in.
Comment 40•22 years ago
|
||
Tooltips has anything to do with values of form widgets???
Comment 41•22 years ago
|
||
what do the tooltips for personal toolbar bookmarks use? They show two lines: bookmark title, then bookmark url. Can that feature be applied to "title" tooltips, allowing multi-line tooltips? Regarding the "replace with space" vs "render as newline" issue, I cast my vote in the "replace with space, but allow tooltips to wrap to mulitple lines" camp. -matt
Comment 42•22 years ago
|
||
Why does web developer put linefeeds here? Is that just a typo? I don't think so. Run the test case in IE, you can see a two lines tooltip was shown. Reply to comment #41: The tooltip for personal toolbar is a two-lines textbox, because we can't get tooltiptext="Google\n\rhttp://www.google.com" work :(
Comment 43•22 years ago
|
||
http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/navigator.xul#285 285 <tooltip id="ptTooltip" noautohide="true" onpopupshowing="return FillInPTTooltip(document.tooltipNode)"> 286 <vbox id="ptTooltipTextBox" flex="1"> 287 <label id="ptTitleText" /> 288 <label id="ptUrlText" /> 289 </vbox> 290 </tooltip> That's what we do for tooltips on bookmarks in the personal toolbar. I'm not sure we can reuse that for title attributes on html elements, but then again I think we should follow the html 4.01 spec and ignore linefeeds and replace carriage returns with a space. Optionally we might choose to wrap long texts instead of cropping them like we do now, though I think title is intended to be a short description, not a screen filling document. Cropping will encourage the former. Kyle: I think you're right that some HTML developers have discovered this bug/feature in IE and are taking advantage of it, but I strongly suspect that there are plenty of pages where the developer hard-wraps the text (by pressing enter) so it fits nicely on his screen and assumes the standard HTML behaviour to apply.
Comment 44•22 years ago
|
||
I'm definately for multi-line support in the attribute. Firstly, cause it's the way IE does it. Secondly, cause I'm using that very same feature in my website (which will not work if the browser would ignore linebreaks).
Comment 45•22 years ago
|
||
We already crop lengthy titles. Try this: <a href="www.mozilla.org" title="this is a really really really really really really really really really really really really really really really really really really really really really really really really really really really really really really really really really really really really really really really really long title">mozilla.org</a>
Comment 46•22 years ago
|
||
See for example comment 13. I strongly doubt the W3 people intended "Extensible Hypertext Markup Language" to be a two-line tooltip with just "Language" appearing on the second line. Jaak: it's cool that your site does what you want it to do in IE, I don't think that's enough of a reason for us to break other sites. Dean: I thought we did, thanks for confirming it.
Comment 47•22 years ago
|
||
Multi-line tooltips are extremely useful for creating an online application that needs some short online help. i.e. -- Press this button to submit your changes. Please make sure that you have entered your e-mail address correctly. -- I think we need some way to break tooltips into multiple lines.
Comment 48•22 years ago
|
||
Reply comment 37: I doubt where is the spec for that converting. I only see those 3 items at http://www.w3.org/TR/html401/types.html#h-6.2 that is for CDATA. And this link is for title attribute: http://www.w3.org/TR/html401/struct/global.html#h-7.4.3 Does it said we must convert linefeeds?
Comment 49•22 years ago
|
||
Some way, maybe. Something as ambiguous (within the context of html at least) as a newline, no. Perhaps "line 1\nline 2" as suggested by Kyle earlier. From a technical point of view, I don't think we should build multiline support into nsTextBoxFrame, we already have a frame that deals with wrapping text, I think we should re-use that instead.
Comment 50•22 years ago
|
||
sure, no probs, it is a minor feature anyway. just have to wait until all people are designing websites for IE (:o), so the multi-lined hints in Mozilla could be turned on, without breaking any websites ;)
Comment 51•22 years ago
|
||
Kyle: http://www.w3.org/TR/html401/struct/global.html#adef-title says that title is of type text. http://www.w3.org/TR/html401/types.html#type-text says that text is %Text; in the DTD http://www.w3.org/TR/html401/sgml/dtd.html#Text says that %Text; is CDATA. So yeah, it does say that.
Comment 52•22 years ago
|
||
"Multi-line tooltips are extremely useful for creating an online application that needs some short online help. i.e. -- Press this button to submit your changes. Please make sure that you have entered your e-mail address correctly." You shouldn't rely on tooltips to convey so much information. If it's not obvious from your form what something does, the form should have the help text directly on it.
Comment 53•22 years ago
|
||
I saw that. jag and dean, you are right.
Comment 54•22 years ago
|
||
"You shouldn't rely on tooltips to convey so much information. If it's not obvious from your form what something does, the form should have the help text directly on it." It was just an example. I use tooltips on my personal webpage in a table if recent visitors. It's just a small table so I cut off the text of the IP address/hostname if it's too long. Hover the mouse over it and the full name gets displayed along with the referrer (referrer on a separate line). Displaying the information every time would hog up way too space, and clicking on a link to go somewhere else to display those two lines would be overkill. The tooltip however, works great for this. I'm just saying that tooltips should have multiple lines. If the title tag won't support it then there should be an alternate way of doing it. Unless you can think of a reason tooltips ought not be able to have multiple lines?
Comment 55•22 years ago
|
||
"Unless you can think of a reason tooltips ought not be able to have multiple lines?" The standard says they shouldn't. See comment 48 and 51. Important quotes from the first link in comment 48 is "Ignore line feeds" and "Replace each carriage return or tab with a single space".
Comment 56•22 years ago
|
||
For an example, i want to use title for IMG object. In the title there will be text like this: " Name: IMG_NAME.jpg Date: 2002-07-18 Scene: World Cup match Poland-Brasil Access: xrwr-r- Author: Jon Smith " It'd be very usefull for me in this and many other situation. Tooltip is very, very helpfull in interface. It doesn't grab space, its easy to implement... Why not?
Comment 57•22 years ago
|
||
nominating for nsbeta1, because there are 14 duplicates and so many complains. We must do something for this, either fix it or mark won't fix :(
Keywords: nsbeta1
Comment 58•22 years ago
|
||
I've sent e-mail to Hixie and dbaron about interpretation of the spec and/or compatibility support. WONTFIX is not the right solution here, there are still black boxes which we shouldn't display. So either this is a dupe of bug 47078 or we need to add support for multiline tooltips (easiest should be to change the tooltip binding to use <xul:html/> instead), which means that when bug 47078 is fixed we'll need to make sure we can somehow get the unchanged data.
Attachment #91779 -
Attachment is obsolete: true
Comment 60•22 years ago
|
||
I'm all in favor of doing the right (read: standards-compliant) thing and duping this against 47078.
Comment 61•22 years ago
|
||
*** Bug 172534 has been marked as a duplicate of this bug. ***
Comment 62•22 years ago
|
||
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 in the text of a title attribute, this SHOULD produce a linebreak. This is the ONLY way to produce a linebreak in attribute text. So I would advise changing the binding and allowing multi-line tooltips as standards-correct. (We could still decide not to respect line breaks when they appear within a tooltip box, just as we don't let them break text in an HTML page except in <pre>, but that would be an internal decision regarding tooltip rendering and have nothing to do with the HTML 4.01 spec.)
Comment 63•22 years ago
|
||
I totally agree with Chris. See comment 37, "Replace each carriage return or tab with a single space.", What does this mean? IMO, It means that we should convert the "invisible* carriage return/tab to a single space, like this: "fooA fooB fooC fooD" => "fooA fooB fooC fooD" But for the soft coded |\n\r|, it should be kept there to satisfy the webdesigner's original intention.
Comment 64•22 years ago
|
||
*** Bug 173025 has been marked as a duplicate of this bug. ***
Comment 65•22 years ago
|
||
*** Bug 178942 has been marked as a duplicate of this bug. ***
Comment 66•22 years ago
|
||
nsbeta1+/adt3 per the nav triage team.
Comment 67•22 years ago
|
||
*** Bug 180279 has been marked as a duplicate of this bug. ***
Comment 68•22 years ago
|
||
*** Bug 182471 has been marked as a duplicate of this bug. ***
Comment 69•22 years ago
|
||
*** Bug 111609 has been marked as a duplicate of this bug. ***
Comment 70•22 years ago
|
||
*** Bug 184700 has been marked as a duplicate of this bug. ***
Comment 71•22 years ago
|
||
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 as a newline and 	 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 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 Therefore: title="foo foo" Display: +---+ |foo| |foo| +---+ Therefore: title="foo	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	foo" Let's not replicate that (Embrace and Improve) :-)
Comment 72•22 years ago
|
||
Nav triage team: nsbeta1-
Comment 73•21 years ago
|
||
I totally agree with Brian's comment 71. Explicit newlines (entities) should be honored, "implicit" newlines converted to spaces. Bug 47078 should deal with the conversion, and in this bug, the issue of making the explicit newlines work should be addressed. It seems that this bug's dependence is the other way around: this _depends_ on bug 47078, and not vice versa. BTW, see also bug 45375 - "tooltips should wrap".
Comment 74•21 years ago
|
||
Here is another page regarding tooltips: http://www.petesguide.com/WebStandards/tests/tooltips.html
Comment 75•21 years ago
|
||
*** Bug 45375 has been marked as a duplicate of this bug. ***
Comment 76•21 years ago
|
||
I too agree with Brian's <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=67127#c71">comment 71</a>. We need a multi line comment and the way of IE is good for us. I think that Mozilla could go the some way. IE is less standard browser but is the more used due to Microsoft bad W3 compliant too. So if Mozilla would replace IE must do what IE do. For now our client use IE. I hope they will use Mozilla soon ;)
Comment 77•21 years ago
|
||
*** Bug 195552 has been marked as a duplicate of this bug. ***
Comment 78•21 years ago
|
||
*** Bug 195913 has been marked as a duplicate of this bug. ***
Comment 79•21 years ago
|
||
*** Bug 198197 has been marked as a duplicate of this bug. ***
Comment 80•21 years ago
|
||
*** Bug 198725 has been marked as a duplicate of this bug. ***
Comment 81•21 years ago
|
||
*** Bug 202178 has been marked as a duplicate of this bug. ***
Comment 82•21 years ago
|
||
If no one is planning to work on it, you can assign it to me.
Comment 83•21 years ago
|
||
finally. Thank you Brian for interesting.
Comment 84•21 years ago
|
||
*** Bug 203639 has been marked as a duplicate of this bug. ***
Comment 85•21 years ago
|
||
*** Bug 204166 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Target Milestone: mozilla1.1alpha → ---
*** Bug 205128 has been marked as a duplicate of this bug. ***
Comment 87•21 years ago
|
||
*** Bug 212973 has been marked as a duplicate of this bug. ***
Comment 88•21 years ago
|
||
* I don't understand why I have to set the height and width manually * I can't get this to work in XBL, only in XUL as shown :-(
Comment 89•21 years ago
|
||
Comment on attachment 129857 [details] [diff] [review] Lame patch Just looking for comments.
Attachment #129857 -
Flags: superreview?(jag)
Attachment #129857 -
Flags: review?(doronr)
Comment 90•21 years ago
|
||
I'm actually working on something similar, but for HTML tooltips :) I think its a hack, wouldn't it be better to: - parse the text for newlines - create seperate dom nodes for each "line"? Note that the embedding tooltip api works correctly :)
Comment 91•21 years ago
|
||
This version makes all tooltips multiline by splitting on newlines but it doesn't handle tabs.
Comment 92•21 years ago
|
||
Neil: why not do the xbl in the setter for the label property?
Comment 93•21 years ago
|
||
I agree with comment 71. So with character entities being turned into their character equivalents, at the DOM end we'll see CRLFs and TABs, right? Then Neil's patch is a good start (if not the answer), and until bug 47078 is fixed, we'll get the complete IE behaviour (modulo "bugs") for free. Once bug 47078 is fixed though, CRLFs in the HTML will become spaces and some of these testcases/sites will stop working as expected (note that IMHO the expectation is wrong). Do we want to introduce this now and "break" things later, or should we wait till bug 47078 is fixed?
Comment 94•21 years ago
|
||
jag: which way do you like better, the pre css one or the splitting version?
Comment 95•21 years ago
|
||
I am sorry, but as I discovered that this Bug, Misbehaviour or "not running along with IE" is a open bug since 2001/01, I am quite disapointed about Mozilla. So many discussions and no solution to a simple problem, which affects a lot of sites and make them hard to use/read, is undescribable situation. Could some please get rid of this Bug... PRETTY PLEASE?
Comment 96•21 years ago
|
||
Re Comment #95 (and anymore potential Me To's) At the top of this bug report, you can see that a patch was attached by Neil on 15/8 (15 August) and is undergoing the official Mozilla review process. Yes, this bug has been around for a while, but I notice that the patch is from someone who is "officially" not part of Mozilla, but is a programmer somewhere who decided to have a go at fixing the problem. While I haven't encountered this bug myself, I thank Neil for his unpaid work on fixing it for all of us. NEIL: Shouldn't this bug be Assigned to you?
Comment 97•21 years ago
|
||
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.
Comment 98•21 years ago
|
||
How about shutting up and letting people fix bugs quietly? What a novelty...
Comment 99•21 years ago
|
||
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.
Comment 100•21 years ago
|
||
What Doron Rosenberg is saying (in a not so polite manner - though I think it wasn't meant to be rude, just humerous ;-) ) is that complaining in a bug will not make it fixed any faster when there is already a patch available.
Comment 101•21 years ago
|
||
re Comment #98. You're right, I should just accept patches quietly, and be just as quiet about any new bugs. I shouldn't thank people for their work as I must be quiet. I shouldn't bother doing any testing as it achieves nothing as I must be quiet. I should not file a Bugzilla bug regarding a problem which I noticed with this bug report as I must be quiet.
Comment 102•21 years ago
|
||
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.
Comment 103•21 years ago
|
||
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.
Comment 104•21 years ago
|
||
Comment 105•21 years ago
|
||
bryner, any idea why we need to reset the height to the boxObject height?
Comment 106•21 years ago
|
||
What is the height before you do that? 0?
Comment 107•21 years ago
|
||
Its the height of one character (original height I believe)
Comment 108•21 years ago
|
||
*** Bug 218873 has been marked as a duplicate of this bug. ***
Comment 109•21 years ago
|
||
About duplicate Bug 218873. i do not get black bars as shown in a screen shot for this bug - i get squares. Though this may just be due to system font etc. Just thought might be worht mentioning. P.s. Sorry about duplicate - but i couldn't search for black bars/lines if i didn't get em :)
Comment 110•21 years ago
|
||
Comment on attachment 129862 [details] [diff] [review] Newline-only patch I prefer this approach.
Attachment #129862 -
Flags: superreview+
Comment 111•21 years ago
|
||
Interested developers please have a look at http://forums.mozillazine.org/viewtopic.php?t=38949
Comment 114•21 years ago
|
||
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 115•21 years ago
|
||
Comment on attachment 136944 [details] [diff] [review] New Patch v0.1 - based on newline-only patch This patch was based on Neil's newline patch so someone else needs to review it.
Attachment #136944 -
Flags: review?(neil.parkwaycc.co.uk) → review?(jag)
Comment 116•21 years ago
|
||
Comment on attachment 136944 [details] [diff] [review] New Patch v0.1 - based on newline-only patch r=jag
Attachment #136944 -
Flags: review?(jag) → review+
Comment 117•21 years ago
|
||
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 118•21 years ago
|
||
Comment on attachment 136944 [details] [diff] [review] New Patch v0.1 - based on newline-only patch sr=bzbarsky
Attachment #136944 -
Flags: superreview?(bz-vacation) → superreview+
Attachment #136944 -
Flags: approval1.6b?
Comment 119•21 years ago
|
||
Comment on attachment 136944 [details] [diff] [review] New Patch v0.1 - based on newline-only patch Requesting approval to get into 1.6beta - fairly low risk but really needs to go into beta and not final
Comment 120•21 years ago
|
||
Won't the following section of the patch only replace the first instance of each of these characters? + label = label.replace("\\n", "\n"); + label = label.replace("\\r", "\r"); + label = label.replace("\\t", "\t"); Shouldn't it use a regex like label.replace(/\\n/g, "\n") instead? There's no guarantee that there will be only one of these characters, right?
Comment 121•21 years ago
|
||
+ // replace all control characters except LF, CR and tab with ? + label = label.replace(/[\x00-\x08]|[\x0B\x0C]|[\x0E-\x1F]/g, "?"); Could we replace them with U+FFFD instead? + label = label.replace("\\n", "\n"); + label = label.replace("\\r", "\r"); + label = label.replace("\\t", "\t"); I assume this doesn't actually convert literal "\n" characters in HTML attributes into newlines. The following: <span title="yes\no">test</span> ...should render with the following tooltip: [ yes\no ] ...not: [ yes ] [ o ] ...right?
Comment on attachment 136944 [details] [diff] [review] New Patch v0.1 - based on newline-only patch Minusing approval request since the patch needs work.
Attachment #136944 -
Flags: approval1.6b? → approval1.6b-
Comment 123•21 years ago
|
||
Re comment#120 erm good point don't why I didn't pick that up Re comment#121 ok I'll spin a patch that uses \uFFFD instead of "?" it was my understanding that we did actually want to convert the literal "\n" characters but I can take that out.
Comment 124•21 years ago
|
||
My understanding was that " " should be converted into \n and " " into \r. (See comment #62.)
Comment 125•21 years ago
|
||
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)
Comment 126•21 years ago
|
||
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?
Comment 127•21 years ago
|
||
Because the spec doesn't even remotely say anything about doing that?
Comment 128•21 years ago
|
||
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.
Comment 129•21 years ago
|
||
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 > Therefore, we should use character entities to insert line-breaks in titletips, and if IE does anything extra (like interpret \n), they are doing it wrong. <span title="yes o">test</span> According to the spec, line-breaks in the HTML file itself appear as whitespace, so that should appear as "yes o" all on one line.
Comment 130•21 years ago
|
||
From my testing <span title="yes 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)
Comment 131•21 years ago
|
||
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 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: * is the character code for line-feed, not a line-feed itself. * We should honor , but ignore hard line-feeds of ascii char 10 (like you'd get from a text editor). * -- 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".
Comment 132•21 years ago
|
||
Just want to express agreement with Brian about the desired behavior: <span title="yes no">test</span> +---+ |yes| |no | +---+ <span title="yes no">test</span> +------+ |yes no| +------+ In addition - and should all produce only one line break, and hard character sequences 13, 10, and 13-10 should all produce only one space. (This is to handle the \r and \r\n newline conventions used by older MAC and DOS respectively.)
Comment 133•21 years ago
|
||
I agree with both Brian and Zack. See previous comments in this thread. Reading Hixie's comment 121, I now disagree with my comment 49, \n should just be displayed as the literal "\n", not as a newline. See comment 93 for what I think should happen, and has been mentioned elsewhere, any newline chars should be treated as whitespace (currently blocked by bug 47078), the entity 
 (or perhaps all of 
, 
 and 
) should be turned into a newline and displayed as such in our tooltips.
Comment 134•21 years ago
|
||
Comment on attachment 137054 [details] [diff] [review] New patch 0.1.5 >+ var vbox = document.getAnonymousElementByAttribute(this, "anonid", "vbox"); >+ if (vbox) { >+ while (vbox.lastChild) >+ vbox.removeChild(vbox.lastChild); >+ // replace all control characters except LF, CR and tab with \uFFFD >+ label = label.replace(/[\x00-\x08]|[\x0B\x0C]|[\x0E-\x1F]/g, "\uFFFD"); Forgot to mention this last time, but could this become something like: /[\x00-\x08\x0B\x0C\x0E-\x1F]/g? >+ // replace tabs with eight spaces >+ label = label.replace(/\x09/g, " "); >+ var labels = label.split(/\n\r|\n|\r\n|\r/); Hmmm, I don't think I've seen \n\r. For a moment I was afraid it could take \r\n\r\n (two DOS newlines) as three newlines by matching \r, \n\r, \r, but in the matching order it would of course match \r\n before matching \r, and never see the \n\r combination. r=jag
Comment 135•21 years ago
|
||
(
) shouldn't do anything special. Since this patch is converting some control characters to U+FFFD, it should do the same with U+000D. Only U+000A inserted by character entity should become a line break. I still don't understand why we're doing the control code conversion thing, nor do I understand how it is being done, or why only a subset of UNICODE control characters is being converted. Why is that special cased at all? Shouldn't the existing code in layout or GFX take care of this? In any case, if DOM/JS uses UTF-16, isn't the following: label.replace(/[\x00-\x08]|[\x0B\x0C]|[\x0E-\x1F]/g, "\uFFFD"); ...going to completely corrupt the output? I really don't understand that part of the code to be honest. Similarly, TAB characters should just be handled by layout; if they're not that's a layout bug too (I'm assuming the tooltip has white-space: pre).
Comment 136•21 years ago
|
||
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 उ test">this is a उ test</span><br/>
Attachment #137054 -
Attachment is obsolete: true
Comment 137•21 years ago
|
||
One of the questions is should we using \uFFFD if JS/DOM is only UTF-16, if not then should we go back to using "?" Web page designers might put the control characters in numerical order hence matching on \n\r as well as \r\n
Comment 138•21 years ago
|
||
Slightly offtopic, but I was wondering: Should we be converting 
 to the equivalent to <br> within the regular document, and not within an attribute? <body> Some text 
 
 
 
 Some more text </body> should this appear as the equivalent to: <body> Some text <br> <br> <br> <br> Some more text </body>
No, and it's off topic.
Comment 140•21 years ago
|
||
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 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).
Comment 141•21 years ago
|
||
> One of the questions is should we using \uFFFD if JS/DOM is only UTF-16, if not
> then should we go back to using "?"
I don't understand this, by the way. What has UTF-16ness got to do with that?
Comment 142•21 years ago
|
||
I'll try to get my brain in better order today - I realised almost as soon as I hit the commit button I'd got myself completely confused on the UTF-16 issue. Anyway, I've already been testing the use of style="white-space: -moz-pre-wrap;" within popup.xml and it seems to be completely ignored. Neil also suggested maybe trying max-width too, but again it has on impact. I tested both with vbox and label, so not sure what is going on with that yet. As mentioned in comment #132 older MACs use 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.
Comment 143•21 years ago
|
||
> As mentioned in comment #132 older MACs use
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 " ", 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 " " or "
"
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)
Comment 144•21 years ago
|
||
Since the patch also provides a fix for bug 45376 which has 88 votes and is very much desired by many ... why not make a temporary fix or spin off just the wrapping part so that it gets into 1.6?
Comment 145•21 years ago
|
||
Bugzilla Bug 45376 You can make a bug depend on itself. - Verified Fixed This bug really has a patch that provides a fix for that? impressive.
Comment 146•21 years ago
|
||
I think he meant bug 45375, which is related and does currently have 88 votes.
In the meantime, it might be reasonable to check in the patch that would be the correct fix once those parser bugs were fixed. This would have the advantage that it gets rid of the unsightly black boxes and that it gives authors a way (avoid literal newlines in title attributes; use 
) 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.
Comment 148•21 years ago
|
||
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?
Comment 149•21 years ago
|
||
> since one would need to decide when to wrap
I'd rather we left wrapping up to the web authors on tooltips (talking from the
perspective of a web author this time), because we might cause a wrap when they
don't want it. It would be nice in some cases, though, for really long tooltips
if we could handle it for them and create the tooltip with a width that was good
for their machine. I don't know how we could accomodate both possibilities, though.
Comment 150•21 years ago
|
||
How about adding a hidden pref, so users can change the wrap-length, if they want to? Set this to 64 (or a bit higher?) as a default should be more then ok. Although I doubt, that many users change the default value it would be nice if people could. It's better, than hardcoding it and better, than an endless discussion, how long that should be at the end.
Comment 151•21 years ago
|
||
Would relating the width of the tooltip to the width of the window it is being generated from be a good idea? Do we want to, temporarily, strip out other control characters that will generate black bars?
Updated•21 years ago
|
Summary: Newline in tooltips converted to black bars → Newline in tooltips (title attribute) converted to black bars
Comment 152•21 years ago
|
||
I've logged bug 228099 to do with the parsing of U+000A as opposed to " " or "
" and bug 228100 for the -moz-pre-wrap issue as per comment#143.
Attachment #136944 -
Attachment is obsolete: true
Comment 153•21 years ago
|
||
Tweaks Doron's patch to use white-space: -moz-pre-wrap. Once bug 228673 is fixed this patch should work.
Attachment #137112 -
Attachment is obsolete: true
Comment 154•21 years ago
|
||
From comment #151: > Would relating the width of the tooltip to the width of the window > it is being generated from be a good idea? This looks like a good idea to me, unless it's easy to solve.
Comment 155•20 years ago
|
||
*** Bug 238889 has been marked as a duplicate of this bug. ***
Comment 156•20 years ago
|
||
*** Bug 152157 has been marked as a duplicate of this bug. ***
Comment 157•20 years ago
|
||
*** Bug 244185 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Flags: blocking1.7+
Comment 158•20 years ago
|
||
standsongrace: Please do not add blocking flags; that's for drivers.
Flags: blocking1.7+
Comment 159•20 years ago
|
||
I just tested using the character in my title attribute for a span in both mozilla and firefox, and they both display a small black vertical bar in win2k, and in linux I get a junk character. Evidently this isn't being handled correctly still.
Comment 160•20 years ago
|
||
*** Bug 248168 has been marked as a duplicate of this bug. ***
Comment 161•20 years ago
|
||
It has been three and a half years since the discovery of this small, yet annoying bug and it is still there :/ I feel like I'm using software from the 'one and only right company'...
Assignee | ||
Updated•20 years ago
|
Flags: blocking1.8a3?
Flags: blocking-aviary1.0RC1?
Flags: blocking-aviary1.0?
Assignee | ||
Updated•20 years ago
|
Attachment #137769 -
Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #137769 -
Flags: review?(neil.parkwaycc.co.uk)
Updated•20 years ago
|
Flags: blocking-aviary1.0RC1?
Flags: blocking-aviary1.0RC1-
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0-
Comment 162•20 years ago
|
||
If we can make progress on getting this reviewed and ready for check in we could consider taking it on the aviary branch. renominate after review. thanks
Comment 163•20 years ago
|
||
*** Bug 113595 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Keywords: mozilla1.0
Comment 164•20 years ago
|
||
I wonder, if Bug 47078 (Newlines are not converted to whitespace in attributes) and Bug 227099 (Parse U+000A, " " and "
" correctly in attributes) should still be blockers for this bug? Both are wontfixed.
Updated•20 years ago
|
Updated•20 years ago
|
Flags: blocking1.8a3? → blocking1.8a3-
Assignee | ||
Updated•20 years ago
|
Attachment #137769 -
Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #137769 -
Flags: review?(neil.parkwaycc.co.uk)
Comment 165•20 years ago
|
||
*** Bug 253899 has been marked as a duplicate of this bug. ***
Comment 166•20 years ago
|
||
Is there any chance that we could temporarily apply a _partial_ patch to this? That is, could we create a patch that would eliminate the actual problem (strange characters in the tooltip when there just happens to be a line break in the HTML) without worrying about adding these new features (change the underlying implementation to allow multi-line tooltips)? My impression is that the difficulties with the current patch are only on the "feature enhancement" side of the issue.
Comment 167•20 years ago
|
||
*** Bug 264570 has been marked as a duplicate of this bug. ***
Comment 168•20 years ago
|
||
Is it really necessary to replace control characters with U+FFFD or "?" here? Why assume the user's font doesn't have a meaningful glyph for these characters? If that substitution is normal/desirable, why isn't it happening in the rendering code instead? If the goal is simply to avoid the "black bars" and replace them with the Unicode REPLACEMENT CHARACTER instead, this seems misguided. If authors have no business specifying control characters in their text, it shouldn't matter if the font's glyph for that character is a square/black bar. The real problem here is that authors felt they *do* have business putting newlines in their "title" attributes. I'm not sure a blanket control character substitution is appropriate as it doesn't appear to be fixing the (right?) problem.
Comment 169•20 years ago
|
||
Just seen it with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a5) Gecko/20041020 Firefox/0.9.1+ the newlines in source code are displayed by some block graphics charcters.
Comment 170•20 years ago
|
||
*** Bug 266448 has been marked as a duplicate of this bug. ***
Comment 171•20 years ago
|
||
Always here in Firefox 1.0 final ...
Comment 172•20 years ago
|
||
*** Bug 269495 has been marked as a duplicate of this bug. ***
Comment 173•20 years ago
|
||
*** Bug 272573 has been marked as a duplicate of this bug. ***
Comment 174•20 years ago
|
||
*** Bug 273144 has been marked as a duplicate of this bug. ***
Comment 175•20 years ago
|
||
It's not so much a case of authors putting significant newlines in their titles as it is a case of insignificant whitespace (as is allowed all through HTML / XHTML) being contained within titles. Consider an acronym tag like: <acronym title="This Is A Longer Than Average Acronym Being Used As An Example">TIALTAABUAAE</acronym>. Theoretically the XHTML author could break this beast up pretty much anywhere and still have it display the same thing (and in fact programs like Tidy will happily break it up to keep individual line lengths under control) and while most rendering engines will do the right thing, Gecko will display black bars.
Comment 176•20 years ago
|
||
. o O (looking at the date this bug was reported I feel this debate is nothing but academical :o)
Comment 177•20 years ago
|
||
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 :-)
Comment 178•20 years ago
|
||
*** Bug 273768 has been marked as a duplicate of this bug. ***
Comment 179•20 years ago
|
||
*** Bug 273854 has been marked as a duplicate of this bug. ***
*** Bug 275450 has been marked as a duplicate of this bug. ***
Comment 181•20 years ago
|
||
(In reply to comment #177) > Wrapping the title is not a good idea because people might want to show a > pre-formatted title, like ASCII art or something less silly :-) I don't think that usage (at least with carriage returns and/or linefeeds) is allowed in standard HTML. The spec says that: '''For all HTML elements except PRE, sequences of white space separate "words" (we use the term "word" here to mean "sequences of non-white space characters"). When formatting text, user agents should identify these words and lay them out according to the conventions of the particular written language (script) and target medium.''' and goes on further to say that: '''In particular, user agents should collapse input white space sequences when producing output inter- word space. This can and should be done even in the absence of language information (from the lang attribute, the HTTP "Content-Language" header field (see [RFC2616], section 14.12), user agent settings, etc.).''' It identifies characters: space ( ), tab (	), form feed (), zero-width space (​), carriage return (
), and line feed (
) 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 (…), line separators (
), paragraph separators (
), etc.) is allowed but is still an extension that HTML authors shouldn't automatically expect to work everywhere. We shouldn't be holding up a fix for something that is an obvious, blatant, embarrassing bug that even shows its bad behavior on the W3C site because some Web page authors (I believe a minority) are currently relying on unspecified behaviors. I'm all in favor of adding support for preformatted titles using next lines, etc., but it should be done at a later date and probably via a separate feature request. The bug should be fixed first, and the enhancement added later.
Comment 182•20 years ago
|
||
Feneric, it looks like you're confusing characters and character entities. See comment 131 for what everyone seems to agree is the correct behaviour. It's just a matter of getting the code patched to do that!
Comment 183•20 years ago
|
||
First, it's only just hit me that this bug was first reported in the context of ALT text for images, but the current summary and the existing patches for the problem apply only to tooltips. Given that newlines in ALT text are still handled improperly (just tested with Firefox 1.0 on Win98), is there any bug still dealing with that (and with newlines handled improperly in other attributes), or should a new one be filed? It seems like many of the ideas being implemented here should apply generally to all attributes (though bug 228099 comment 7 points out why quirks mode should avoid these replacements for the "value" attribute, at least). And second, in reply to comment #182: > Feneric, it looks like you're confusing characters and character entities. See > comment 131 for what everyone seems to agree is the correct behaviour. It's > just a matter of getting the code patched to do that! It looks to me like Feneric's point is essentially the same one that I made in comment 166. This bug started life as a request to honor the HTML specification by treating whitespace as whitespace rather than changing some of it into visible characters. But at some point, it evolved into a worthy but rather different enhancement request to enable pre-formatted (multi-line) tooltips using explicit character entities. I agree that this enhancement is a valid and useful reading of the specification! But I'm not convinced that the two issues are related, either conceptually or in the code. As I understand it, solving the original problem should just be a matter of replacing every block of whitespace in a title attribute with a single space ("s/\w+/ /g", I think), and there's probably already code somewhere that does that ("white-space: normal" in CSS, for instance). Even if it's not quite that easy, the original problem can't possibly have anything to do with the current blocking bug 228673 (which wouldn't arise here at all without patch v0.4's change to browser.js that enables multi-line tooltips). In short, it looks to me like the original bug could probably be fixed without too much trouble by those who know the code. (Please correct me if that's wrong!) But instead, that fix is being incorporated into a complicated enhancement with a fairly low apparent priority. So why not spin off the enhancement into its own bug (or if it's easier at this point, create a new bug for the original issue and relabel this one), and in the meantime check in a fix for the original problem?
Comment 184•20 years ago
|
||
FWIW that latest patch is still valid, just the line numbers have changed. I tried it and it worked fine, except for a problem I noticed with 'normal' tooltips. If there was no newline in the title attribute, the tooltip box was twice as high as it needed to be. Something like this would fix it: if (t.search(/\n/) >= 0) { tipNode.setAttribute("height", tipNode.boxObject.height); } else { tipNode.setAttribute("height", tipNode.boxObject.height - 16); } I'm sure the height of the tooltip (16 on my PC) is stored somewhere else and is not a fixed value. And although I agree with much of comment 183 that this bug has gotten off track, it's only a 2 or 3 line fix that would solve the original problem! Why doesn't someone do it! (I've got no idea how to make one of those diff files, otherwise I'd give it a go myself.)
Comment 185•20 years ago
|
||
*** Bug 277528 has been marked as a duplicate of this bug. ***
Comment 186•19 years ago
|
||
*** Bug 278848 has been marked as a duplicate of this bug. ***
Comment 187•19 years ago
|
||
*** Bug 278972 has been marked as a duplicate of this bug. ***
Comment 188•19 years ago
|
||
*** Bug 280167 has been marked as a duplicate of this bug. ***
Comment 189•19 years ago
|
||
A testcase for acronym tooltip with \n(LF) and \t charcters inside.
Comment 190•19 years ago
|
||
*** Bug 287094 has been marked as a duplicate of this bug. ***
Comment 191•19 years ago
|
||
*** Bug 216592 has been marked as a duplicate of this bug. ***
Comment 192•19 years ago
|
||
*** Bug 67127 has been deleted, removed due inactivity. *** /Sarcasm End Since more than 4 years a bitterly fight goes over an tiny problem. But this problem got some powder in itself and nevertheless it threatens to split a religion and couse civil war, disaster and a lot of death. Why? Cause it means, W3C seen as pontifex of WWW is unfailable and not questionable. Or should the masses get their rights and tell and use learned methods for themselfs, without considering the wishes of the wise and lonely top? I estimate we have an answer to a problem in 5 more years, which solved itself due time automatically. And everybody, who dont wont to wait this long period of war, I tell: http://piro.sakura.ne.jp/xul/_popupalt.html.en#download Maybe, this brave act of an civillian will help us to lead the pontifex W3C to a better way of understanding of their people. (Well, me personaly think, nope, but we must provide a positive way for our W3C.) PS: Couldnt stop me from writing this, since I look up this matter for a long time now. *Flame start here*
Comment 193•19 years ago
|
||
*snort*hahahahaha*snort* Sorry, you commented in the wrong bug, this is not the alt-as-tooltip bug.
Comment 194•19 years ago
|
||
Yeah, but Piro's extension fixes this bug too. Actually when this bug started Moz could still display ALT text as evidenced by the first test case which is demonstrating the "black bars". Black bars that are not even visible now because the ALT text is not displayed. Perhaps that makes this bug "invalid"
Comment 195•19 years ago
|
||
(In reply to comment #194) > Yeah, but Piro's extension fixes this bug too. Actually when this bug started > Moz could still display ALT text as evidenced by the first test case which is > demonstrating the "black bars". Black bars that are not even visible now > because the ALT text is not displayed. I don't follow you. Mozilla _does_ display ALT text, and always(?) has: when the image is unavailable or when it hasn't loaded yet. That's what ALT text is for: an alternative way of conveying image content. (And that's pretty clearly the context of the original report, which mentions that the display of the text is different depending on whether the image is still trying to load or whether Mozilla has given up.) As I said in comment #183, I've tested this myself with Firefox 1.0 and the ALT text bug is still there (as is the tooltip problem, of course).
Comment 196•19 years ago
|
||
I've just tried. Firefox doesn't display the alt text when the images are not displayed.
Comment 197•19 years ago
|
||
(In reply to comment #196) > I've just tried. Firefox doesn't display the alt text when the images are not > displayed. Did you try the original reporter's testcase? (That is, create a local file whose contents are the HTML snippet he gave: the linked testcase URL for the bug was apparently changed to a tooltip example at some point.) I've got that case open in another tab right now (Firefox 1.0.1 on OS X), and the ALT text is shown, strange box characters and all.
Comment 198•19 years ago
|
||
OK, Firefox displays the alt text only when the images are shown (I don't think this condition is a good idea, since the goal of the alt text is to give some information when the image is not visible, but well...).
Comment 199•19 years ago
|
||
*** Bug 292990 has been marked as a duplicate of this bug. ***
Comment 200•19 years ago
|
||
XML 1.0 spec., section 3.3.3 Attribute-Value Normalization sais: For a white space character (#x20, #xD, #xA, #x9), append a space character (#x20) to the normalized value. So I think that no new line in attribute can be rendered (at least in XHTML).
Comment 201•19 years ago
|
||
I´m not sure I see the reason for this year-long discussion - the specs state clearly that newlines and similar are to be replaced with white-space. The reason probably being that such characters aren´t valid in all encodings(Win/Unix for example). Nowhere it says that a browser mustn´t break long lines - shouldn´t a tooltip be handled the same way regular HTML is? I.e. if it´s too long for one line - break it. There is no way an author can know in advance how many characters he can use - so breaking the line at window-end seems to be the only reasonable solution - and it´s something the UA has to do, not the web-author. (Sorry if I repeated what someone else said - I didn´t read the entire thread, I skipped portions.)
Comment 202•19 years ago
|
||
(In reply to comment #201) > I´m not sure I see the reason for this year-long discussion - the specs state > clearly that newlines and similar are to be replaced with white-space. The > reason probably being that such characters aren´t valid in all > encodings(Win/Unix for example). > > Nowhere it says that a browser mustn´t break long lines - shouldn´t a tooltip be > handled the same way regular HTML is? I.e. if it´s too long for one line - break it. > There is no way an author can know in advance how many characters he can use - > so breaking the line at window-end seems to be the only reasonable solution - > and it´s something the UA has to do, not the web-author. > (Sorry if I repeated what someone else said - I didn´t read the entire thread, I > skipped portions.) I'd suggest to direct your attention to comment #62, which BTW perfectly describes my own opinion as I don't like idea of violating the standards yet I'm sure web-authors definetely should have the possibility of breaking line at a particular position.
Comment 203•19 years ago
|
||
2 Questions: 1. What is 'Patch v0.4 based on Doron's patch' exactly doing? It it doing, what has been suggested in Comment #62 and/or Comment #71? 2. Why wasn't review or superreview being requested for this patch?
Comment 204•19 years ago
|
||
*** Bug 296920 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 205•19 years ago
|
||
(In reply to comment #203) > 2 Questions: > 1. What is 'Patch v0.4 based on Doron's patch' exactly doing? It it doing, what > has been suggested in Comment #62 and/or Comment #71? > 2. Why wasn't review or superreview being requested for this patch? The answer to 2 is that either it doesn't work, or isn't acceptable for some reason. I don't recall the details, but there are some subtleties here. If I remember correctly, Neil rejected the patch on IRC. Explicitly messing with the boxObject.height is almost certainly not the correct solution.
Comment 206•19 years ago
|
||
For the record, Ubuntu bug http://bugzilla.ubuntu.com/show_bug.cgi?id=12998 is the same bug as this one, with another test case, another use case, and another sarchastic comment (comment #3)
Comment 207•19 years ago
|
||
*** Bug 313154 has been marked as a duplicate of this bug. ***
Comment 208•19 years ago
|
||
*** Bug 321593 has been marked as a duplicate of this bug. ***
Comment 209•19 years ago
|
||
As I suggested in comment 183, I have just spun off the originally reported issue in this bug (regarding black boxes in images' ALT text) into bug 322413. Both that new bug and this one are now set to depend on bug 322270, which I recently filed to deal with whitespace in attributes generally. After those changes, it might be reasonable to make this bug's summary reflect its current focus: enabling multi-line tooltips. (But it should probably still mention the black bar problem, too, to help people find the problem.) I'll leave it to the bug owner to make that decision.
Comment 210•18 years ago
|
||
This bug is still open. Cmon guys - lets fix it before its 6th anniversary ;-)
Assignee | ||
Comment 211•18 years ago
|
||
(In reply to comment #210) > This bug is still open. Cmon guys - lets fix it before its 6th anniversary ;-) > You got a patch?
Comment 212•18 years ago
|
||
(In reply to comment #210) > This bug is still open. Cmon guys - lets fix it before its 6th anniversary ;-) To summarize the current status of this bug: The "black bars" problem will be (essentially) fixed as soon as bug 322270 is fixed. That bug's owner has set a target milestone of mozilla1.9alpha, which I believe means "in time for Firefox 3". (It sounds like there may be some fairly low-level changes involved, which may be more than the 1.8 branch is expected to handle at this point.) The "multi-line tooltips" enhancement that's also been discussed in this bug is a somewhat independent issue. If bug 322270 is fixed in a way that allows the desired behavior in comment 131, then the parsed value of the "title" attribute will include actual line feed characters for each " " in the source. We'll then want the tooltips themselves to behave something like "white-space: -moz-pre-wrap" as suggested in comment 140 (though wrapping tooltips may deserve a separate bug). As I see it, the main danger in implementing the eventual fix for multi-line tooltips before bug 322270 is fixed is that page authors might mistakenly think that we were endorsing the standards-violating MSIE behavior (and get upset when the eventual fix limiting them to the method in comment 131 landed). But if anyone can make a patch for this work, we'd all love to see it.
Comment 213•18 years ago
|
||
Extension Popup ALT Attribute fixes this bug for me and enables multi-line tooltip. I didn't had any strange behavior with it, so it maybe can help with fixing those bugs.
Comment 214•18 years ago
|
||
This patch eliminates the "black bars" in tooltips (only) by collapsing whitespace when the tooltip text is retrieved. It makes no attempt to enable multi-line tooltips, and in fact it will need to be reverted for that to happen. That being said, this fix removes an ugly behavior that's a blatant Firefox bug and replaces it with a behavior consistent with the HTML standards. The effect of this patch in practice will be essentially identical to the effect of a fix for bug 322270 (with or without any patch here). And since that bug's current target makes it unlikely that a real solution here will be possible before Firefox 3, maybe this fix would be reasonable to include in the meantime. Thoughts?
Attachment #210603 -
Flags: superreview?(bzbarsky)
Attachment #210603 -
Flags: review?(jag)
Comment 215•18 years ago
|
||
Comment on attachment 210603 [details] [diff] [review] Interim patch: collapse whitespace (no multi-line) I won't be able to get to this within any sort of reasonable time frame... Please ask someone else for sr?
Attachment #210603 -
Flags: superreview?(bzbarsky)
Updated•18 years ago
|
Attachment #210603 -
Flags: superreview?(alecf)
Comment 216•18 years ago
|
||
*** Bug 326049 has been marked as a duplicate of this bug. ***
Attachment #210603 -
Flags: superreview?(alecf) → superreview+
Updated•18 years ago
|
Attachment #210603 -
Flags: review?(jag) → review?(bryner)
Updated•18 years ago
|
Attachment #210603 -
Flags: review?(bryner) → review+
Comment 217•18 years ago
|
||
Comment on attachment 210603 [details] [diff] [review] Interim patch: collapse whitespace (no multi-line) If I'm asking the wrong person for branch approval, let me know. Also, I don't have a CVS account, so I will need someone else to actually land this (whether on trunk or on branch).
Attachment #210603 -
Flags: approval-branch-1.8.1?(bryner)
Updated•18 years ago
|
Whiteboard: [checkin needed]
Updated•18 years ago
|
Attachment #210603 -
Flags: approval-branch-1.8.1?(bryner) → approval-branch-1.8.1+
Comment 218•18 years ago
|
||
*** Bug 331016 has been marked as a duplicate of this bug. ***
Patch checked in to both trunk and MOZILLA_1_8_BRANCH, into both browser/base/content/browser.js and xpfe/browser/resources/content/browser.js .
Comment 220•18 years ago
|
||
*** Bug 337505 has been marked as a duplicate of this bug. ***
Updated•18 years ago
|
Whiteboard: [checkin needed]
Comment 221•18 years ago
|
||
i'd like to add something constructive to this bug. allowing multiline tooltips is a *very* bad idea. eventually someone will create a tooltip that covers your whole screen. i've repeatedly warned gecko people about this. i'd like to take a moment to note that i've actually seen this happen in a product that happened to ship with gecko (it wasn't the gecko part that did this, but that's not the point). we were in a video conference with a customer and i moved the customer's mouse pointer over some portion of the screen, and all of a sudden, the entire screen flickered yellow for an instant and then went back to normal. this happened a number of times and we really panic'd. we had no idea what was going on, or why. now, that was when we were dealing with screens that were 1024x768 or larger. the screens i'm looking at today are 800x480. imagine if your screen, which is say ~3"x2" all of a sudden flickers solid yellow. would you be happy? i wouldn't, and i'd expect my mother and my sister to take their device back to the store and inform them that it's broken and that they want their money back. not all geckos come for free, sometimes paying customers have valid reasons for complaining about bad decissions. tooltips should be *short* helpful *tips*, not long discourses about the meaning of the universe. (42 is a valid tooltip, the full transcript about The Answer to Life, the Universe, and Everything, taking a number of volumes and written using pixels on a standard human screen is not a valid tooltip.) there's a reason that people suggested a LONGDESC attribute to images in addition to the TITLE attribute. Also to be kept in mind is that as with my example above, tooltips have this tendency of disappearing in response to a timer. if you can't read the tip faster than the timer, then the tip is too long. i've had that problem with the product i described above. the ui designers were nice people, but they didn't consider what would happen when you stuffed lots of text into a small timer. For people who persist in wanting tooltips, and it's a slippery slope, if i let someone have 4 lines and 30 chars per line, someone will try to get 5 lines and 50 chars, and the next person will use 10 lines and 100 chars. and none of these measurements will fit on my screen. I've been getting a number of bugs in the past few days from people complaining about message texts not fitting into the display. this is a real concern. stop the slippery slope, don't let tooltips grow beyond one line. if a web designer or any designer needs more than one line to explain something, then the designer has made a huge error and should be forced to rethink it. (oh, and tooltips in general fail to be accessible and are amazingly hard to use on the device with which i'm working, not everyone has a mouse. at this point i rarely have mice. sometimes i have clickable widgets, but the idea of dragging a mouse with me everywhere just to find that someone has left 10 essays hidden throughout his web page is insane.
Comment 222•18 years ago
|
||
it occurs to me that this was the wrong bug. i'm sorry. i blame someone else for asking about multiline tooltips and then saying "oh, so why are they fixing this bug" and pointing at this bug. but i'm sorry, i should have remember that this wasn't the right bug. but boy, it's really fun to spam hundreds of people who have voted for the wrong bug.
Comment 223•18 years ago
|
||
timeless: <sarcasm>Are we going to disable DIVs? Because you know they can be huge and can cover your screen on mouseover with yellow (and they say other colors as well). This reminds me of the JavaScript issue, ...</sarcasm> Please don't attempt to save the web, and let web-authors make their choice. (Regadrless of what you think about their capabilities.) Applies for length of title-attribute value too. no offense, have a nice day JZ
Comment 224•18 years ago
|
||
Re: Comment 221: I strongly disagree. Yes, multi-line tooltips are bad in some scenarios. They are also EXTREMELY helpful in other scenarios. In fact, I have developed an application that relies on these, and of course it won't work with Firefox in its current state. Design decisions should be made by designers, not forced by the platform developers.
(In reply to comment #223) > <sarcasm>Are we going to disable DIVs? Because you know they can be huge and > can cover your screen on mouseover with yellow (and they say other colors as No, DIVs can cover the part of the browser window in which the Web page is displayed. That's a smaller area than the screen, and there's a huge difference between the ability to cover one and the ability to cover the other. (In reply to comment #224) > Design decisions should be made by designers, not forced by the platform > developers. Browsers should be designed for the benefit of their users; sometimes users do need to be protected from malicious authors. (If you don't believe that, try disabling popup blocking for a bit.)
Comment 226•18 years ago
|
||
If browsers are designed for the benefit of their users, then there would be a setting that would limit the number of characters in a tooltip. But a character cutoff with no redress by the user or the website author, especially when all the other browsers I know of don't have a character cutoff, just doesn't make any sense. I recommend maximum flexibility for both the user and the website author, in place of the Firefox design team's _hard_ decision to cut off tooltips at a point that pleases only them.
Comment 227•18 years ago
|
||
(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.
Comment 228•18 years ago
|
||
*** Bug 343434 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 229•18 years ago
|
||
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)
Assignee | ||
Comment 230•18 years ago
|
||
(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?
Comment 231•18 years ago
|
||
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.
Assignee | ||
Updated•18 years ago
|
Attachment #236663 -
Flags: review?(neil)
Assignee | ||
Comment 232•18 years ago
|
||
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
Assignee | ||
Comment 233•18 years ago
|
||
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
Assignee | ||
Updated•18 years ago
|
Keywords: fixed-seamonkey1.1b
Comment 234•18 years ago
|
||
Re: Comment #233: That's an interesting attitude. As a developer, you're basically saying: "I don't care what the QA people think (let alone the lowly users)".
Assignee | ||
Comment 235•18 years ago
|
||
(In reply to comment #234) > Re: Comment #233: That's an interesting attitude. As a developer, you're > basically saying: "I don't care what the QA people think (let alone the lowly > users)". > The few good QAs who haven't submitted any patches at all know that it doesn't apply to them. I really *don't* care what the users think in this case, because there are too many of them, and they have too many different opinions. On bugs like this, not making it clear that I don't care what users think results in bugs with hundreds of comments and hundreds of cc'ed people, which makes it hard to get work done.
Comment 236•18 years ago
|
||
(In reply to comment #232) > I'm marking this bug fixed and moving it to the product that existed at the > time it was filed. I won't object too strenuously to changing the product as you have, but I do find it a little odd: this bug has morphed enormously since it was filed (the original summary was "Newline in ALT attribute of IMG tag causes black square to be displayed"), so insisting on taking it back to its roots in one particular way at this point seems unnecessary and perhaps confusing. (Especially since the Firefox interim was posted here, too: it might be nice if a search that specified "Firefox" or "Core" would turn this up.) As for marking it as fixed, I generally agree (given its current summary). But as I just noted, the bug has morphed substantially since its last summary change: until my interim Firefox patch, the vast majority of the work on this bug would have been better summarized as something like "Enable multi-line tooltips" (I advocated a summary change explicitly in comment 209 and implicitly in several other places). If you're going to mark it as fixed based on its current summary, you (or, well, someone) really ought to file a bug to cover the issue that has been this bug's de facto focus for the past four years. Copying over the main conclusions here (comment 131 and perhaps some implementation ideas like the proposed patches or even suggestions like the -moz-pre-wrap idea in comment 140) would be very helpful. Assuming that that gets done, I completely support this change.
Assignee | ||
Comment 237•18 years ago
|
||
(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. �A; ) are indistinguishable from the values they represent (e.g. \n). I don't think that requested behavior fits with the spec. I said more in my reply on the other bug. Regarding comment 140, doesn't my patch match that? I think it does, based on my memory (I'm not on a machine that has a patched build right now) of the patch vs. an experiment with -moz-pre-wrap.
Comment 238•18 years ago
|
||
Sorry for the spam, but where's the bug for multi-line tooltips in Firefox? My understanding is that even if the newlines are interpreted correctly by Gecko, Firefox's XUL still needs fixing. So what's that bug? I'd like to vote for it.
Comment 239•18 years ago
|
||
(In reply to comment #238) > Sorry for the spam, but where's the bug for multi-line tooltips in Firefox? I've just filed it: it's bug 358452. I've tried to summarize there the current status of the issue, and the conclusions that were reached here. It's probably good to have that feature request in its own bug anyway, since this bug's summary was never clearly related to the multi-line enhancement. (Also note that bug 218223 is closely related: that's the bug for allowing long tooltips to wrap automatically in Firefox.)
Comment 240•15 years ago
|
||
The ToolTip Torture Test (see URL) still fails for line breaks but the main issue of this bug is gone. VERIFY. HTML compliance may need another fresh bug.
Status: RESOLVED → VERIFIED
Comment 241•15 years ago
|
||
Hb: please see if the remaining issues are covered by bug 358452 and/or bug 322270, and file new bugs if not.
Comment 242•15 years ago
|
||
Dependency on bug 228673 and on bug 322270 deleted. This bug here gave an interim fix which was overcome by the one in 322270. Discussion here circled for more than 4 years around the MSIE vs. Web standards compatibility. During that time new standards arose which made an agreement not easier. All remaining issues have been filed to bugzilla.
See Also: → https://launchpad.net/bugs/19250
Comment hidden (spam) |
Comment hidden (spam) |
Comment hidden (spam) |
Comment hidden (spam) |
You need to log in
before you can comment on or make changes to this bug.
Description
•