Closed Bug 218223 Opened 21 years ago Closed 17 years ago

Long tooltips should allow wrap to multiple lines

Categories

(Firefox :: General, defect, P2)

Product:
Firefox
Component:
General
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 3 alpha4

People

(Reporter: bugs, Assigned: Gavin)

References

Details

Attachments

(2 files, 5 obsolete files)

patch with nits fixed and pinstripe changes
5.87 KB, patch
Gavin
: review+
Details | Diff | Splinter Review
long title overflows SM-window
63.78 KB, image/jpeg
Details 
Firebird version of bug 45375
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → Firebird0.10
QA Contact: asa
*** Bug 222697 has been marked as a duplicate of this bug. ***
*** Bug 242605 has been marked as a duplicate of this bug. ***
Target Milestone: Firefox1.0beta → After Firefox 1.0
I use these tooltips a LOT and see no reason why they can't be corrected by
Firefox 1.0.  I thought Firefox was standards compliant?  Walk your talk.
Neill Dumont, your comment does nothing to add to the value of this bug. Please
don't waste our time with useless advocacy comments or your account will be
disabled. 
Does this bug depend on Bug 99457? Should I/someone add the dependancy?

*** Bug 263500 has been marked as a duplicate of this bug. ***
*** Bug 264862 has been marked as a duplicate of this bug. ***
OS: Windows XP → All
Hardware: PC → All
Attached image illustration of why tooltip should wrap (obsolete) — 
here is a site where the last crucial information from the tooltip is snipped
http://www.pp.co.nz/CPUs-AMD.php
(In reply to comment #8)
> Created an attachment (id=167580)
> illustration of why tooltip should wrap
> 
> here is a site where the last crucial information from the tooltip is snipped
> http://www.pp.co.nz/CPUs-AMD.php

Please see comment 4 before making comments that do not contribute to the
resolution of the bug.
dupe

*** This bug has been marked as a duplicate of 45375 ***
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
(In reply to comment #10)
> dupe
> 
> *** This bug has been marked as a duplicate of 45375 ***

Isn't this a firefox bug and Bug 45375 a Suite bug?

If so, I request this be re-opened.. if Bug 45375 applies to both FF and the
Suite then I request it is marked as such..

Thanks
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 280251 has been marked as a duplicate of this bug. ***
*** Bug 281966 has been marked as a duplicate of this bug. ***
Attached image tooltip bug (obsolete) — 
tooltip can't also handle new line
(In reply to comment #14)
> Created an attachment (id=174546) [edit]
> tooltip bug
> 
> tooltip can't also handle new line

Yes, indeed that is what this bug is about and what many of the proposed patches
have been meant to do.  Please, we are not blind; I don't think this bug needs
any more screenshots.

To anyone who has the power: can this bug be, perhaps, renamed to "Tooltips
should wrap and show multiple lines" or some other more verbose description like
the Mozilla equivalent has?

Thanks,
-[Unknown]
> To anyone who has the power: can this bug be, perhaps, renamed to "Tooltips
> should wrap and show multiple lines" 
I support that suggestion /jeff
Sorry to be a pest, but I don't :) I'm in favour and support the idea of
tool-tip text being managed sensible (i.e. wrapped) so that it is visible but I
am not in favour of newlines in the attribute being interpreted as breaks. We
don't do this for CDATA (e.g. you need explicit BRs, or Ps) so it shouldn't be
done for attributes, IMHO.

I guess at the core there are two bugs.
(In reply to comment #17)
> Sorry to be a pest, but I don't :) I'm in favour and support the idea of
> tool-tip text being managed sensible (i.e. wrapped) so that it is visible but I
> am not in favour of newlines in the attribute being interpreted as breaks. We
> don't do this for CDATA (e.g. you need explicit BRs, or Ps) so it shouldn't be
> done for attributes, IMHO.
> 
> I guess at the core there are two bugs.

I find the implementation which also allows linebreaks to be show as if <pre>
but would like it even better if it were to be able to be formatted with BR P
(even others like STRONG EM ...) 

There are sites that discovered that formating with simple linebreaks could make
the information clearer.  I can't see any reason to not support increased
clarity. Though I would even support having tags in title be evaluated (tho I
suspect that "hardcore" "specificationalists" would have an even harder time 
with that)

I want to be able to honestly say that FF is better that IE even in this case.
(which it isn't right now) /Jeff

(In reply to comment #18)

> There are sites that discovered that formating with simple linebreaks could
> make the information clearer.  I can't see any reason to not support
> increased clarity.

I find that sites which have enough information in the attributes so that
formatting like this becomes necessary should really put the information
elsewhere. Bear in mind that pop-ups are not available in all browsers, do not
show up when printed, etc.

> Though I would even support having tags in title be evaluated (tho I suspect
> that "hardcore" "specificationalists" would have an even harder time with
> that)

XML attributes cannot contain < > or &
> I find that sites which have enough information in the attributes so that
> formatting like this becomes necessary should really put the information
> elsewhere.


"necessary" is a dangerous word like "obvious" "should" which always must be
related to a defined goal to have real meaning. 

My most common use for the title attr is in marking links. Goal: To help the
person that is about to click be extra sure that that link will take him where
he wants to go or not, or maybe warn him about some detail he should know.

I find myself often in conflict with the "clean" page people that want to have
"the ten commandments" with only the "necessary" 6 best ones because "people
can't read things on the internet as though they were printed"  

I feel like a good title attr is a nice way to hit a middle ground with a
relatively clean page that stills gives relevant extra info for a link or button
choice.

And I still want FF to be better than IE even in this case. At least give the
user chance to chose which rendering he/she wants.  (Why would anyone want to
NOT see the way a person, that obviously and consciously tried (often in spite
of sticky fingered editors that rearrange code), has written the title attr? Oh
well, there might be some.)  

>XML attributes cannot contain < > or &
I guess XML does not forbid line breaks in the code(or you would have mentionsed
that), which would in that case make it possible for FF to render them. That
sounds promising.

> I find that sites which have enough information in the attributes so that
> formatting like this becomes necessary should really put the information
> elsewhere. Bear in mind that pop-ups are not available in all browsers, do not
> show up when printed, etc.

There are times when it's necessary to put a flood of information in title tags,
such as on an online user manual or training graphic rollovers (which was what
my original complaint had to do with in the first place).

It's frustrating for a few reasons:
(1) There are sometimes tooltips in other places that are longer than 80
characters, esp. links and the like (though Firefox does not touch such things
in the same nature that Aiiiiieeeeee does unless the <a> tag has some sort of
special title attribute, and even then...).
(2) I don't mean to sound crass, but if IE can do it, why can't Firefox? 
(Please do not kill me...) Firefox has kicked IE's *ahem* up and down the
markets, what with 25 million downloads in four months and it has features that
IE will probably never have, but it can't handle title tags properly...

Is there anything I can do to help here?
*** Bug 287094 has been marked as a duplicate of this bug. ***
That's also my opinion. It is a fact that there ARE REASONS why the title
attribute is longer than 80 characters and should be wrapped instead of cut off.

I am currently writing a business application that is displaying a mass of
geographic points on a map by using html layers. there are about 200 or more
points on the map to be displayed at once (e.g. movement history). If the user
wants to have more detailed information on a special point like time, speed or
other information he just has to move the mouse over the point to see the
content of the title attribute. this works fine in IE but a firefox user won't
see all information he needs. I don't think that there would be a more practical
solution available than to use the title-attribute for this reason.

hans
*** Bug 292136 has been marked as a duplicate of this bug. ***
*** Bug 295031 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
No longer blocks: majorbugs
*** Bug 300747 has been marked as a duplicate of this bug. ***
*** Bug 301781 has been marked as a duplicate of this bug. ***
*** Bug 302692 has been marked as a duplicate of this bug. ***
*** Bug 306085 has been marked as a duplicate of this bug. ***
*** Bug 306675 has been marked as a duplicate of this bug. ***
*** Bug 316513 has been marked as a duplicate of this bug. ***
shouldn't this bug depend on bug 228673 if it has the same problems as suite bug 45375?


(In reply to Bryan Yu comment #14)
> Created an attachment (id=174546) [edit]
> tooltip bug
> 
> tooltip can't also handle new line

that is Bug 67127
Summary: Long tooltips should wrap → Long tooltips should allow wrap to multiple lines
*** Bug 336407 has been marked as a duplicate of this bug. ***
My little contribution for web developers frustraded of this bug: you may find useful a javascript workaround such this one: (Bubble Tooltips) http://www.web-graphics.com/mtarchive/001717.php or this one: http://www.walterzorn.com/tooltip/tooltip_e.htm
The major news website slate.com has just launched a new "Documents" series which relies on long <TITLE> tooltips.  At present, it's unusable with Firefox.

Example: http://www.slate.com/id/2142381

I've contacted them, but I don't really expect a fix (although Slate is no longer owned by Microsoft).
Depends on: 228673
I'm following up on this bug, which from the surface seems to be the same issue being discussed in bug 45375 for SeaMonkey but is really a core Gecko issue. It seems that this bug has been an issue for over six years, but is now becoming much more of an issue as web developers are starting to use the TITLE attribute as it was intended by W3C specifications. For instance very common web applications like vBulletin now make use of the TITLE attribute quite heavily as do many other sites.  As a result this bug has become a major functionality issue that really needs it priority and severity raised so that it gets the attention it needs to get resolved. See bug 45375 for the long testimonials about the usability issues this bug is causing.

It seems kind of crazy that a bug of this nature has languished for six years.

There's been some recent activity related to this issue that I thought should be mentioned in this bug.  Specifically, bug 356900 was recently filed and fixed: from the sound of it, the patch there essentially fixes bug 45375 (the SeaMonkey version of this bug) and bug 67127 (whose focus for years has been trying to allow explicit line breaks in tooltips; it was just recently relabeled as a SeaMonkey-only bug, though I'm not quite sure why).  There may be difficulties that I'm not expert enough to recognize, but it's possible that this SeaMonkey patch could be adapted to fix the same two issues for Firefox.

The most important caveat that I can see is the desired behavior of newline characters in tooltip text (yes, that's a bit off-topic for this bug, but important if anyone goes to implement this).  That issue was discussed thoroughly in bug 67127, and the best conclusion found was described in bug 67127 comment 131.  If a Firefox patch along the lines of the fix for bug 356900 is created, I would recommend that my interim patch for bug 67127 be left intact until bug 322270 is fixed (which will deal with whitespace in attribute values more generally).
Ok, this problem is there since 2004-12-01

2 years and XXXXX releases later, this is still unfixed.
Damn, is there any gecko's developer around here, or is it a faked bugzilla?

Is it normal to still have ugly tooltip behaviors in this software?
Is it planned to be fixed in something less than 10years (as the target milestone for this bug is marked as 'FUTURE' which means 'never, but we don't want to say it'. )
Some sites are based on tooltips and you can use these sites with Firefox.
Like this site: http://www.hair-science.com/_int/_en/topic/topic_sousrub.aspx?tc=ROOT-HAIR-SCIENCE^PORTRAIT-OF-AN-UNKNOWN-ELEMENT^SUPERB-CHEMISTRY&cur=SUPERB-CHEMISTRY
Hover over "amino acids" or "hydrogen bonds".
Flags: blocking-firefox3?
Couldn't Mozilla's fondation use some of their 44,7 millions dollars $$$ benefits to correct this bug?
Money doesn't equal ability to get work done. Just look at IE. If you want this to be fixed, just vote for it and stop the comment spam. This is a high priority issue for me too, but begging here is only going to annoy the people who are already watching the issue.
Assignee: bugs → nobody
Status: REOPENED → NEW
QA Contact: general
This was motivated by the arrival of my copies of Lockpick Pornography and Truth and Beauty Bombs, which reminded me of Ryan North asking so nicely for this fix at a dinner last year.  Probably branch-worthy after some trunk baking, but possibly incompatible with extensions which assume that tooltip has no children, so we'd have to hold off for a 2.0.1.x.

This fails the second test on http://www.webdevout.net/testcases/title_tooltips/ (no line break), in exchange for passing test 3 (not looking like total crap).  We can reverse that decision by removing the newline stripping line (see the comments also for why we have to make that choice).

I am violently, vehemently not [ ] taking this bug.
Attachment #253778 - Flags: review?
Attachment #253778 - Flags: review? → review?(gavin.sharp)
Attached patch As above, but unified and such. (obsolete) — — Splinter Review 
Whoops.
Attachment #253778 - Attachment is obsolete: true
Attachment #253782 - Flags: review?(gavin.sharp)
Attachment #253778 - Flags: review?(gavin.sharp)
(In reply to comment #42)
> This fails the second test on
> http://www.webdevout.net/testcases/title_tooltips/ (no line break), in
> exchange for passing test 3 (not looking like total crap).  We can reverse
> that decision by removing the newline stripping line (see the comments also
> for why we have to make that choice).

As I understand it, SeaMonkey chose the non-stripping behavior to allow authors to add explicit newlines, and because it matches IE behavior. Are we not better off to do the same, for the same reasons? I suppose that means a change in behavior when bug 322270 is fixed, if it is. At the very least, if we go with this approach, the XXX comment should mention bug 322270.
Priority: P3 → --
Target Milestone: Future → ---
I have no objection to following that path.  I probably won't get to it until the weekend -- do you want to do that as a follow-up patch, or do you think we'll be making things worse by putting this in as-is?
Assignee: nobody → gavin.sharp
No longer depends on: 228673
Priority: -- → P2
Target Milestone: --- → Firefox 3 alpha3
Version: unspecified → Trunk
Status: NEW → ASSIGNED
I would strongly object to implementing the IE behavior here.  Part of that is selfish: my motivation for fixing bug 67127 was to eliminate the bizarre tooltip problems I encountered just because I word-wrapped my HTML (which should have no effect, according to the HTML spec).  Switching to the IE behavior would re-break Firefox's tooltips, and would require some sort of further fix in the future.  (And a future fix /is/ important: bug 322270 affects much more than just tooltips.)  Personally, I'm much more interested in keeping whitespace handling remotely sensible than I am in the ability to add line breaks to my tooltips.

I think that it would invite many intense complaints if Firefox briefly supported IE's incorrect behavior here and then later removed that support.  (To many users, it would seem like we had endorsed a de-facto standard and then abandoned it.)  As I see it, it would be much more reasonable to hold off on allowing author-specified newlines in tooltips until we can tell the web developer community "Here's a /good/ (and standards compliant) way to implement this."  We could try to tell people to use &#13; rather than just hitting enter to be ready for the future fix, but I doubt that many would do so as long as they act the same way.


Getting back to this patch as written, a quick note on the HTML spec itself (as implemented in the current patch here): I've always been bothered by the difference in handling of CR and LF in the specification, because it means that identical-looking code written on different platforms may render differently.  I don't know what to do about that (apart from hoping that a future version of the standard fixes the problem), but it's why I went somewhat non-standard in my earlier fix to bug 67127.  Meanwhile, I don't think that the spec says anything about whether or not the /rendering/ of a tooltip should collapse whitespace or not; my philosophy is that if we do it for plain text by default in HTML and CSS, why shouldn't we do it for tooltips?  I've discussed this in some depth at bug 356900.
In theory, I would assume that any displayed version of the title attribute (such as in a tooltip) should be derived from the attribute value as it exists in the DOM. The value in the DOM should have the whitespace collapsed like normal. Therefore, the displayed tooltip shouldn't be retaining any newlines or sequences of whitespace from the raw source.

Character references are a different issue, since (I believe) they are supposed to be translated after the initial whitespace collapsing, and therefore the characters referenced don't collapse like normal whitespace.

I agree with Steuard; adding new incorrect behavior isn't the way to go.
FWIW I've added my vote to this bug, however I agree with the sentiment that whilst wrapping long lines to make them visible ought to be done, explicit line breaks and other types of formatting should not be done unless there is a standards compliant way to go.
Flags: blocking-firefox3? → blocking-firefox3+
The patch (as it is at https://bugzilla.mozilla.org/attachment.cgi?id=253782 right now) applies

   t = t.replace(/[\r\t]/g, ' ');

and

   t = t.replace(/\n/g, '');

I beg your pardon, why the empty string in the latter?
What if t == 'multiple\nwords'?

Also, the 'white-space: -moz-pre-wrap;' is going to preserve subsequent white spaces instead of collapsing (folding) them together, isn't it?

Then t.replace(/\s+/g, " ") is probably necessary unless you're going to become too MSIE-compatible. This bug is about wrapping to multiple lines; collapsing or not collapsing white spaces in tooltips is probably a different and independent issue.
The different treatment of \r and \n in the current patch follows directly from the HTML spec (in the section referenced in the patch), which (as I noted at the end of comment 46) I find less than pleasant: that's why I broke slightly from the standard with my "s/\s+/ /g" replacement.  I'd love to understand why the spec reads as it does here.

Meanwhile, yes, the right place to discuss policy on author-specified line breaks (and related whitespace issues, I'd think) is probably bug 358452 (Firefox) or bug 67127 (SeaMonkey, but originally more general).  I'd rather see this bug (and any patches to it) focus on the automatic wrapping issue.

Oh, and as a side note, my understanding from bug 357337 is that CTho's SeaMonkey patch in bug 356900 actually breaks when incorporated with the reflow branch (my impression was that the solution on the reflow branch would actually be much simpler, but I won't swear to that).  Has the current patch here been tested on both 1.8 and 1.9?
(In reply to comment #49)
> The patch (as it is at https://bugzilla.mozilla.org/attachment.cgi?id=253782
> right now) applies
> 
>    t = t.replace(/[\r\t]/g, ' ');
> 
> and
> 
>    t = t.replace(/\n/g, '');
> 
> I beg your pardon, why the empty string in the latter?

Because, in the section of the HTML specification that I explicit mention in the patch you link to, that's what it says to do with newline characters, no?  That was my reading of it, but if I made a mistake in my interpretation I'm more than open to correction.
->alpha4. Alpha3 is gone.
Target Milestone: Firefox 3 alpha3 → Firefox 3 alpha4
not to be a pest but this bug was reported 4 years ago. it's upsetting that had to user FIND on the html source code in order to read some image title text on sites like xkcd which makes frequent use of long mouseover image text. How much money do you guys need to fix this? I can start a collection plate, just put a price tag on it.

Best Regards
In Firefox I need to view source and use Find to search for a tooltip keyword in the source text in order to read the complete tooltip text. Internet Explorer handles it beautifully.
Why search source if you can view title in Properties
> How much money do you guys need to fix this?

I think the general reply to this would be, "We don't need money, we need a developer to do it."

> Why search source if you can view title in Properties

I didn't think of that. It is quite unobvious.
There's a patch to fix this issue here in this bug, and if you had bothered to read the bug before commenting on it you would have seen both the patch and the discussion.  Neither advocacy comments nor additional test cases are helpful at this point, unless the test cases vary incorrectly in behaviour after the patch is applied.  Please do not comment on this bug unless you are providing specific feedback on the patch or the plan described for fixing it.  Thank you.
(In reply to comment #58)
> Please do not comment on this bug unless you are providing
> specific feedback on the patch or the plan described for fixing it.

You're doing the exact same thing by responding to it.
So are you.(In reply to comment #59)
> (In reply to comment #58)
> > Please do not comment on this bug unless you are providing
> > specific feedback on the patch or the plan described for fixing it.
> 
> You're doing the exact same thing by responding to it.
> 

So are you =)
(In reply to comment #59)
> (In reply to comment #58)
> > Please do not comment on this bug unless you are providing
> > specific feedback on the patch or the plan described for fixing it.
> 
> You're doing the exact same thing by responding to it.

I wrote the bloody patch, and am following the bug for review feedback and to get it in the tree, so I'm telling people to keep the noise down so that the bug stays useful.  I won't really be upset about disabling people's accounts if they aren't contributing productively.

(In reply to comment #60)
> So are you =)

Yep.

(In reply to comment #61)
> so I'm telling people to keep the noise down so that the
> bug stays useful.

"Don't post advocacy" comments have already been made a million times on this page.  If you want to scold those who continue to do it, reply to their email directly so it isn't cluttering up the bug for the rest of us.

I would be replying privately right now, except I want to draw attention to a proposed solution:

https://bugzilla.mozilla.org/show_bug.cgi?id=377311
(In reply to comment #62)
> I would be replying privately right now, except I want to draw attention to a
> proposed solution:

If you reply privately, you will be in violation of the Bugzilla Etiquette (section 1, paragraph 4):
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Please take it to heart. :)
That etiquette policy explicitly states "please place all information relating to bugs in the bug itself. Do not send them by private email."  Asking people to keep the advocacy comments out of the bug is not information relating to the bug, so it seems to me it would be appropriate to send privately.
> I find that sites which have enough information in the attributes so that
> formatting like this becomes necessary should really put the information
> elsewhere. Bear in mind that pop-ups are not available in all browsers, do not
> show up when printed, etc.
>
Yes, but in the cases where they exist, shouldn't we be able to read them? IE seems to handle these cases fine. Why is this just a problem for FF to address? it's been an issue for several years.

XKCD.com chooses to embeded verbose in these tags as a sort of hidden message for insiders. But one can imagine a site where the pages are generated programmatically and some description text is inserted into these tags automatically. Should we lobby w3c to put a clause in the HTML spec to limit text in these tags to 80 characters? or should we just wrap lines so that people can read the text when it appears in the tool-tip? This seems the obvious solution, and the solution implemented in IE.
>>Please do not comment on this bug unless you are providing
specific feedback on the patch or the plan described for fixing it.

Sorry, I'm new here and still learning my way around. Not really sure what blocking/wanting flags are and all that. I only noticed that it was reported in 2003 and the STATUS is still ASSIGNED to this day. No more advocacy comments from me.
There are a couple of remaining minor issues (unnecessary wrapping in some cases), which as far as I can tell are due to bug 228673 and bug 357337. There is also the outstanding issue of whether we want to do the whitespace stripping or not, but I don't want to let that block progress here, so I'm going to land this patch and file a follow up on determining the exact behavior we want to ship with.
Attachment #167580 - Attachment is obsolete: true
Attachment #174546 - Attachment is obsolete: true
Attachment #253782 - Attachment is obsolete: true
Attachment #261394 - Attachment is obsolete: true
Attachment #262651 - Flags: review+
Attachment #253782 - Flags: review?(gavin.sharp)
mozilla/browser/base/content/browser.css 	1.24
mozilla/browser/base/content/browser.js 	1.778
mozilla/browser/base/content/browser.xul 	1.341
mozilla/browser/themes/pinstripe/browser/browser.css 	1.45
mozilla/browser/themes/winstripe/browser/browser.css 	1.58

This bug is now FIXED on the trunk. Filed bug 378620 to make a decision about the whitespace stripping before the release.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago → 17 years ago
Resolution: --- → FIXED
Just a screenshot. The tooltip should may be resize himself relatively to window-size.

*[title] {
white-space: pre;
}

Is a great idea.
Sorry I have meant its good, that the title-atribut-value is formated as predefined text.
At this page http://forum.mozilla-russia.org/viewtopic.php?pid=177188#p177188 are two icons (UA of browsers)... Hover it... Tooltip small for first and big for second...

Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9a4pre) Gecko/20070425 Minefield/3.0a4pre
(In reply to comment #69)
> The tooltip should may be resize himself relatively to window-size.

I would say it shouldn't. Other Windows applications (Windows Explorer, Microsoft Word...) also display overlapping tooltips, e.g. when you hover a toolbar button that is near the window border.
(In reply to comment #71)
> At this page http://forum.mozilla-russia.org/viewtopic.php?pid=177188#p177188
> are two icons (UA of browsers)... Hover it... Tooltip small for first and big
> for second...

I don't see that problem, using a Mac trunk build. Could you file a bug on it, and CC me?
(In reply to comment #73)
> (In reply to comment #71)
> > At this page http://forum.mozilla-russia.org/viewtopic.php?pid=177188#p177188
> > are two icons (UA of browsers)... Hover it... Tooltip small for first and big
> > for second...
> 
> I don't see that problem, using a Mac trunk build. Could you file a bug on it,
> and CC me?
> 

Filed Bug 378846
Depends on: 382937
Depends on: 378846
Should there be an update to Firefox 2 to fix this? The bug has been fixed (i.e the code has been written), so I don't see why it should take another 6 months for a minor change like this to get into a stable version that people will actually use.

> Should there be an update to Firefox 2 to fix this?

I agree that there should -- but there won't be. Unless it's deemed a "security vulnerability", you won't see the fix until the next major release. Unless of course you use the "nightly builds", which contain the fix -- but also an assortment of half-baked unfinished features with new bugs that crash your system and lose your data.

This is frustrating and unsatisfactory, but it is widely considered a necessary evil in software engineering. IE and Opera are no better in this regard, and they don't give you the option of using the nightly builds.
I'm not completely positive, but I'm quite sure that the (simple) fix from this bug depends on some much larger fixes in other bugs in order for it to function properly (aka, the Reflow Branch), hence why it can't be easily backported to Fx2.
Verified fixed using Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9b3pre) Gecko/2008010705 Minefield/3.0b3pre ID:2008010705 and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b3pre)Gecko/2008010801 Minefield/3.0b3pre

-> Verified fixed
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: