Last Comment Bug 101565 - <nobr>'d text doesn't wrap at end-of-line
: <nobr>'d text doesn't wrap at end-of-line
Status: RESOLVED WORKSFORME
: compat, testcase
Product: Core
Classification: Components
Component: Layout: Block and Inline (show other bugs)
: Trunk
: x86 All
: -- normal (vote)
: ---
Assigned To: layout.block-and-inline
: Hixie (not reading bugmail)
Mentors:
http://www.mozilla.org/tinderbox.html
: 139429 (view as bug list)
Depends on: 191699
Blocks: 280339 274716 278891
  Show dependency treegraph
 
Reported: 2001-09-25 10:53 PDT by Mrten
Modified: 2008-06-05 01:50 PDT (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
see the 'cvs update -D date' disappear from the page in this png (8.39 KB, image/png)
2001-09-25 16:24 PDT, Mrten
no flags Details
testcase (668 bytes, text/html)
2001-12-28 16:09 PST, Mrten
no flags Details
Testcase from dupe (435 bytes, text/html)
2002-04-26 09:18 PDT, José Jeria
no flags Details
reflow log (5.89 KB, text/plain)
2002-05-09 10:13 PDT, Bernd
no flags Details
Another pic showing problem (9.41 KB, image/gif)
2002-05-10 05:56 PDT, José Jeria
no flags Details
Another testcase (782 bytes, text/html)
2002-06-10 00:25 PDT, David Simpson
no flags Details
Yet another pic showing problem (16.64 KB, image/png)
2002-06-10 00:32 PDT, David Simpson
no flags Details
Test cases with and without tables from Bug 278891 (993 bytes, text/html)
2005-10-06 18:34 PDT, Hallvard B Furuseth
no flags Details

Description Mrten 2001-09-25 10:53:33 PDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4+) Gecko/20010924
BuildID:    2001092403

if you look down on the page i mentioned and find the text 'cvs update -D date',
and play with the width of the page so that that text is at the end of the line,
it doesn't flow to the next line as expected but goes out-of-view.

in the HTML it is <nobr>'d, which probably accounts for this behaviour.




Reproducible: Always
Steps to Reproduce:
1. go to url
2. seek 'cvs update -D date' just below 'The tree is on fire...'
3. play with width of window so that 'cvd update' is @ end-of-line
4. see 'cvs update -D date' disappear


Actual Results:  couldn't read 'cvs update -D date'

Expected Results:  wrapped the text to the next line, so that the text would
actually be *readable*.
Comment 1 Boris Zbarsky [:bz] 2001-09-25 16:05:02 PDT
<nobr> is _supposed_ to make text not wrap...

Marking invalid.  Reopen if there is a good reason we should be wrapping here in
spite of the <nobr> tag
Comment 2 Mrten 2001-09-25 16:18:23 PDT
i guess you either misunderstood, or my description may be a bit vague: 

<nobr> should make text not wrap, agree, but the <nobr>'d text AS A WHOLE should
stay visible as long as possible, and therefore, wrap.


suppose you've got the following HTML-fragment:

a b c d e <nobr>f g h i j</nobr> k l m n o p 

that should be rendered as such:

-----------------
| a b c d e     |
| f g h i j k l | 
| m n o p       |
-----------------

instead of:

-----------------
| a b c d e f g h i j 
| k l m n o p   |
|               |
-----------------

i hope this futile attempt at ascii-art makes my point a bit clearer. :)
Comment 3 Mrten 2001-09-25 16:24:32 PDT
Created attachment 50784 [details]
see the 'cvs update -D date' disappear from the page in this png
Comment 4 Boris Zbarsky [:bz] 2001-09-25 17:59:26 PDT
reopening per reporter's comments.  My apologies for the misunderstanding.
Comment 5 Keyser Sose 2001-11-09 19:04:32 PST
Marking these all WORKSFORME sorry about lack of response but were very
overloaded here. Only reopen the bug if you can reproduce with the following steps:

1) Download the latest nightly (or 0.9.6 which should be out RSN)
2) Create a new profile
3) test the bug again

If it still occurs go ahead and reopen the bug. Again sorry about no response
were quite overloaded here and understaffed.
Comment 6 Boris Zbarsky [:bz] 2001-11-10 09:05:50 PST
No, this is a valid bug.
Comment 7 Håkan Waara 2001-12-27 18:11:44 PST
Mrten, is it possible that you could create a *reduced* testcase here that
demonstrates the bug? It would be helpful so we can track down the buggy code.

Thanks
Comment 8 Mrten 2001-12-28 16:09:58 PST
Created attachment 62970 [details]
testcase

it is difficult to reproduce the problem. i tried replacing the text with
repeated  occurences of 'text ', but then it would not reproduce. it seems that
the source-formatting is important to reproduce (weird?), but i have not
identified a pattern yet.
Comment 9 Jo Hermans 2002-04-23 10:09:01 PDT
see bug 139429 for a simple testcase
Comment 10 Boris Zbarsky [:bz] 2002-04-23 10:29:44 PDT
*** Bug 139429 has been marked as a duplicate of this bug. ***
Comment 11 José Jeria 2002-04-26 09:18:02 PDT
Created attachment 81159 [details]
Testcase from dupe
Comment 12 Håkan Waara 2002-05-08 12:48:18 PDT
The last testcase (with a <nobr> written past the end of a <td>) makes me think
this is a table bug.   Bernd, can you confirm?
Comment 13 Bernd 2002-05-09 10:13:26 PDT
Created attachment 82924 [details]
reflow log

the reflow log for attachment 81159 [details] shows that this is a linelayout issue not
computing the maxElementSize (MES) correctly. So Hwaara please keep your layout
bugs away from html-table there are already enough bugs. But Waterson gets
really started when he reads the acronym MES :-)
Comment 14 José Jeria 2002-05-10 05:56:32 PDT
Created attachment 83034 [details]
Another pic showing problem

This is screenshot is taken from
http://www.aftonbladet.se
Showing the same problem as in attachment 81159 [details]. But the code in this site is
not using NOBR at all.
Comment 15 José Jeria 2002-05-10 06:19:39 PDT
Maybe my last comment is bug 117365?
Comment 16 David Simpson 2002-06-10 00:24:38 PDT
I'm also seeing this bug on:

Mozilla 1.0: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0)
Gecko/20020530

I'm attaching some test HTML and a low-quality jpeg of the page redering in
Mozilla and MSIE
Comment 17 David Simpson 2002-06-10 00:25:34 PDT
Created attachment 87079 [details]
Another testcase
Comment 18 David Simpson 2002-06-10 00:32:39 PDT
Created attachment 87080 [details]
Yet another pic showing problem 

This shows the rendering of the sample by msie (on the left) and mozilla (on
the right).  Sorry if these pics are unnecessary.
Comment 19 Christopher Hoess (gone) 2003-06-07 14:11:44 PDT
->B&I, as bernd says this is a line layout problem.
Comment 20 Vedran Miletic 2003-10-05 08:20:31 PDT
retargeting
Comment 21 Boris Zbarsky [:bz] 2003-10-05 11:07:35 PDT
.
Comment 22 Matthew van Eerde 2005-09-29 12:45:05 PDT
As a real-life example see:
http://www.trigeminal.com/index.asp?1036

The languages in the yellow box at the top of the screen are each wrapped in
their own individual <nobr></nobr>... but they shouldn't be overwriting each
other.  There is real space between each </nobr> and the next <nobr>.
Comment 23 Hallvard B Furuseth 2005-10-06 18:30:23 PDT
Bug 278891 has one simple example without tables, and one with.
Seems to be a dup of this bug.
Comment 24 Hallvard B Furuseth 2005-10-06 18:34:30 PDT
Created attachment 198761 [details]
Test cases with and without tables from Bug 278891
Comment 25 John C. Wong 2006-02-23 09:54:46 PST
We’re having problem using NOBR with Firefox  1.0.6 (Mizolla 5.0), Netscape 7.1 (Mozilla/5.0 ) and Netscape 8.1. Somehow if the line is too long, it won’t automatically wrapped. As a result, the line is truncated. We’ve created a reduced test case that demonstrates the problem. For instance, with the snippet below (in red border), the last couple cells, “Categorization Spider” and “Autocategorization” were truncated.

<tr>
<td style="border: 4px solid red">Browse Folders,Search Folders,Maintain Content,<nobr>My Content Status,</nobr><nobr>Unpublish Content,</nobr><nobr>Categorization Spider,</nobr>Autocategorization
</td>
</tr>

Without NOBR, Firefox/Netscape have no problem inserting linebreaks to handle the long runs content. This is not a problem in IE. 

Below is the complete test case, please see “$$$$ NOBR Problem!!!!” and “$$$$ No problem - since there is no nobr”.

Is it the a dup of 101565? Any info on this will be greatly appreciated

Thanks,
John


<html>
<head>
<title>Test</title>
</head>
<body>
<br>
<!-- End Pagelet=PAPP_SITE_MANAGER_HOMEPAGE --></td>
<td width="6"></td>
<td width="33%" valign="top"><!-- Begin Pagelet=PAPP_CONTENT_MANAGER_HOMEPAGE --><!-- PageletState=MAX -->
<table id="PAPP_CONTENT_MANAGER_HOMEPAGE" class="PTPAGELET" width="100%" cellpadding="0" cellspacing="0" border="1">
<tr>
<td valign="top" height="100%" width="100%" style="border: 2px solid green !Added by JWONG4">
<table cellspacing="0" cellpadding="3" height="100%" border="0" width="100%">
<tr>
<td valign="top" height="100%" width="100%" class="EOPP_SCSECTIONFOLDER">
<table cellspacing="0" border="0" width="100%" cellpadding="0" style="border: 2px solid blue !Added by JWONG4">
<tr>
<td valign="top"><a target="_parent" title="Edit and review the spider crawled content."></a></td>
<td width="1%"></td>
<td valign="top" width="100%"><a target="_parent" title="Edit and review the spider crawled content.">Categorized Content</a></td>
</tr>

<tr>
<td valign="top">&nbsp;</td>
<td></td>
<td valign="top">
<table cellspacing="0" cellpadding="0" border="0" width="100%" style="border: 2px solid green !Added by JWONG4">
<tr>
<td></td>
</tr>
<tr>
<td width="100%" style="border: 2px solid purple !Added by JWONG4">
<table cellspacing="0" cellpadding="0" border="0" width="100%">

<tr>
<!--- $$$$ NOBR Problem!!!! -->
<td style="border: 4px solid red !Added by JWONG4">Browse Folders,Search Folders,Maintain Content,<nobr>My Content Status,</nobr><nobr>Unpublish Content,</nobr><nobr>Categorization Spider,</nobr>Autocategorization
</td>
</tr>

<tr>
<!---  $$$$ No problem - since there is no nobr -->
<td style="border: 2px solid green !Added by JWONG4">Browse Folders,Search Folders,Maintain Content,My Content Status,Unpublish Content,Categorization Spider,Autocategorization
</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
</table>
</body>
</html>
Comment 26 Julian Hall 2006-10-09 04:49:14 PDT
This bug has been for open longer than 5 years.  I'm still seeing it in firefox 1.5.
Comment 27 Wayne Mery (:wsmwk, NI for questions) 2006-11-28 13:12:57 PST
(In reply to comment #17)
> attachment (id=87079) [edit] testcase

despite the checkins to blocking Bug 191699, "unbroken text goes hereshould_be_on_next_line" doesn't go on next line. 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061116 Minefield/3.0a1
Comment 28 David G 2008-04-10 09:54:43 PDT
I have been responsible for investigating a very closely related bug and creating a workaround for it over at the English Wikipedia. This is bug seems to be very closely related to [[Bug 225946]] and [[Bug 278891]] (those are two reports of the same nowrap bug) and many of the other bugs that turn up when I search for "nowrap" here.

Since it might be of help, here is our how-to guide about it at Wikipedia and a link to more info about it at the talk page: 
* http://en.wikipedia.org/wiki/Wikipedia:Line_break_handling#Nowraplinks_shortcomings
* http://en.wikipedia.org/wiki/Wikipedia_talk:Line_break_handling#Firefox_bug

Note, that guide is about handling line wrapping in general but those two links are directly to the sections about this Firefox bug. 

The bug is still visible on my Firefox 2.0.0.9 on a WinME. ( Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9 )

.../David
Comment 29 Boris Zbarsky [:bz] 2008-04-10 10:02:49 PDT
This bug as filed is worksforme on trunk....  I bet the textrun changes fixed it.

Note that some of the testcases are about slightly different issues.  Probably the result of overly aggressive dup-marking.
Comment 30 Martijn Wargers [:mwargers] (not working for Mozilla) 2008-06-05 01:50:25 PDT
Yeah, this is worksforme too, using:
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008060207 Minefield/3.0pre

I'm marking this bug worksforme. If someone is still seeing issues with one of the testcases in this bug (I couldn't really see any), please file a new bug for that.
Remember, this is fixed on trunk (Firefox 3), not Firefox 2.

Note You need to log in before you can comment on or make changes to this bug.