Closed Bug 14280 Opened 25 years ago Closed 24 years ago

{ll}   breaks line after special characters [INLINE]

Categories

(Core :: Layout, defect, P2)

x86
Other
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: christian.mattar, Assigned: buster)

References

()

Details

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

Attachments

(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
Status: NEW → ASSIGNED
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 (www.3dnews.net), but breaks still after images (www.firingsquad.com)
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: <html> <head> </head> <body> <table border=1> <tr> <td width=20> <img src="images/jupiter.gif" style="border:solid red">&nbsp;&nbsp;XXXXXXXXXXXXXXXXXXXX </td> <td>blabla</td> </tr> </table> </body> </html>
Could be TABLE related..but definitely not the parser ( attaching content-model ): docshell=01101970 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.
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: M16 → M17
Nom. nsbeta3, recc. nsbeta3+. Important for 4xp compatibility of HTML 3.2 table layout.
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 compatibility.
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 downgraded.
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 patch (deleted) — Splinter Review
Blocks: 23034
fix checked in 9/11/00 r=karnaze
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Whiteboard: [nsbeta3+][PDTP2] [fix in hand] → [nsbeta3+][PDTP2]
Blocks: 32191
Fixed in the Sept 12 build.
Status: RESOLVED → VERIFIED
*** 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.

Attachment

General

Created:
Updated:
Size: