Closed Bug 14280 Opened 20 years ago Closed 19 years ago

{ll}   breaks line after special characters [INLINE]


(Core :: Layout, defect, P2)






(Reporter: christian.mattar, Assigned: buster)




(Keywords: css1, Whiteboard: [nsbeta3+][PDTP2])


(3 files)

In the attachment, the text in the table cell breaks, although it shoulnd't.

Change the special character to a normal character, and it works fine.
The bug also appears with <IMG>s after &nbsp;
Assignee: troy → kipp
Looks like an block/inline issue
Severity: normal → major
Target Milestone: M15
Could this be related to bug 2418 ?
Summary: &nbsp; breaks line in conjuction with other special characters → {ll} &nbsp; breaks line in conjuction with other special characters
It now seems to work with special characters (, but breaks still
after images (
Target Milestone: M17 → M13
I'm going to close this bug unless someone can come up with a compelling reason
for why <img>&nbsp should be have specially...
Should you break around the images at all if there isn't whitespace?  I would
think not, but I'd have to check...
That was my thought when I filed this bug.
It definitely doesn't behave so in IE and Netscape 4.x.
Updating to default Layout Assignee...kipp no longer with us :-(
Why are you re-reassing layout bugs? Do NOT touch layout bugs.

The bugs are assigned to Kipp so they can stay neatly organized until we have a
new owner for the block/inline code.
mass moving all Kipp's pre-beta bugs to M15.  Nisheeth and I will
prioritize these and selectively move high-priority bugs into M13 and M14.
Assignee: kipp → rickg
manna from heaven, rickg
Keywords: css1
Summary: {ll} &nbsp; breaks line in conjuction with other special characters → {ll} &nbsp; breaks line after images
Assignee: rickg → harishd
Moving to my list.
Summary: {ll} &nbsp; breaks line after images → {ll} &nbsp; breaks line after images and special characters
I'd say this has something to do with the way tables are laid out.  The width of
a cell is allowed to automagically adjust to accept larger contents.  It seems
Mr Seamonkey would rather break an &nbsp; than stretch a cell... which is
something no other browser I've ever seen does...

I would much rather have Mozilla stretch cells than break "non-breakable"
spaces... hey -- it only seems logical (but that's never stopped anyone before  :)
Modified test case:



<table border=1>

<td width=20>
<img src="images/jupiter.gif" style="border:solid 
red">&nbsp;&nbsp;XXXXXXXXXXXXXXXXXXXX </td>


Could be TABLE related..but definitely not the parser ( attaching content-model 

html@0205F40C refcount=5<
  head@0205F39C refcount=2<
  Text@0200CCB0 refcount=3<\n\n\t>
  body@0200C23C refcount=3<
    Text@0204E590 refcount=3<\n\n>
    table@0204E29C border=1 refcount=7<
      tbody@0204E0DC refcount=3<
        tr@0204E06C refcount=3<
          td@0204DF10 width=20 refcount=4<
            Text@0204DC90 refcount=3<\n>
            img@0204DC20 src=images/jupiter.gif style=border-top-width: medium; 
border-top-style: solid; border-top-color: red; border-right-width: medium; 
border-right-style: solid; border-right-color: red; border-bottom-width: medium; 
border-bottom-style: solid; border-bottom-color: red; border-left-width: medium; 
border-left-style: solid; border-left-color: red;  refcount=3<>
            Text@02049C50 refcount=8<\u00a0\u00a0XXXXXXXXXXXXXXXXXXXX >
          td@02049B60 refcount=4<
            Text@0204D8E0 refcount=3<blabla>
    Text@0204D790 refcount=3<\n\n>

Assigning to chrish.
Assignee: harishd → karnaze
Steve, this is a dup of another bug that I assigned to Kipp's list, but I can't 
remember what the bug number is. I remember that a special character (maybe even 
the exact same character as in the attachment) caused the containing line to be 
too tall.
Assignee: karnaze → buster
moving all buster m15 bugs to m16.
Target Milestone: M15 → M16
Important to fix, but won't make beta2.
Priority: P3 → P2
Target Milestone: M16 → M17
Nom. nsbeta3, recc. nsbeta3+. Important for 4xp compatibility of HTML 3.2 table 
Keywords: 4xp, nsbeta3
correctness & backward compat. with existing content on the web.
Keywords: correctness
Approving for beta3: ekrock and buster seem to believer that is is important for 
Whiteboard: [nsbeta3+]
related to bug 32191?
Summary: {ll} &nbsp; breaks line after images and special characters → {ll} &nbsp; breaks line after images and special characters [INLINE]
PDT is guessing that this is pretty common... and hence is blessing the current 
P2 priority.  IF it is truly rare... then this compatibility issue might be 
Whiteboard: [nsbeta3+] → [nsbeta3+][PDTP2]
It turns out, this is two different bugs.  Failing to break after non-ascii 
characters when the first character is an &nbsp; is a regression Kipp introduced 
in nsTextTransformer.cpp version 1.29 while fixing bug 16886.  I have a fix for 
that and will attach a patch shortly.

Failing to break after an image is an entirely separate issue.  I have submitted 
that as bug 51439.  Those on the cc list can add themselves to that bug if they 
wish to track it's progress, or plea for it's nsbeta3 status.
Summary: {ll} &nbsp; breaks line after images and special characters [INLINE] → {ll} &nbsp; breaks line after special characters [INLINE]
Whiteboard: [nsbeta3+][PDTP2] → [nsbeta3+][PDTP2] [fix in hand]
Attached patch proposed patchSplinter Review
Blocks: 23034
fix checked in 9/11/00
Closed: 19 years ago
Resolution: --- → FIXED
Whiteboard: [nsbeta3+][PDTP2] [fix in hand] → [nsbeta3+][PDTP2]
Blocks: 32191
Fixed in the Sept 12 build.
*** Bug 23034 has been marked as a duplicate of this bug. ***
M17? Sheesh. Clearing target milestone; nominating for Mozilla 1.0.
Keywords: mozilla1.0
Target Milestone: M17 → ---
Whoah... Sorry. Massive brain fart. Disregard.
Keywords: mozilla1.0
Target Milestone: --- → M17
You need to log in before you can comment on or make changes to this bug.