Closed Bug 3094 Opened 21 years ago Closed 20 years ago

Layout problem with filled table cells


(Core :: Layout: Tables, defect, P3)

Windows 95





(Reporter: thefan, Assigned: buster)




Check out my website at the URL above (  Look
for the words "Making Draco" in the left most column.  If you compare this
output to that of MSIE 4.x or Netscape 4.x you'll see a layout problem.
Assignee: troy → karnaze
Component: Layout → HTMLTables
Looks table related
Assignee: karnaze → troy
The table layout is different from Nav for at least 2 reasons; neither of these
are strictly table related. First, the text field is longer causing the table to
be wider, but this text field can be made the same size as Nav, by selecting Nav
Quirks mode in the viewer.

The other problem is the thin line to the right of the draco image. The table
cell code is being told by its area frame that it has a max element size larger
than its desired size. The area frame should be fixed to not do this. The viewer
will (after my next checkin) print a message when this happens. I have included
a simpler test case below which illustrates the problem.

<table border="0" cellspacing="0" cellpadding="0">
    <td width="186" height="218" colspan="5"><a
src="http://slip/projects/marvin/bugs/images/draco-ss.jpg" width=186 height=218
    <td width="1" rowspan="4" bgcolor="#808080">
       <img src="http://slip/projects/marvin/bugs/images/ilm_spacer.gif" width=1
    <td width=12 rowspan="4" align="LEFT" bgcolor="black">
       <img src="http://slip/projects/marvin/bugs/images/ilm_line.gif" width=12
Assignee: troy → karnaze
This doesn't make sense. The area frame doesn't do anything with
max-element-size. Maybe you're referring to the block code?
Assignee: karnaze → kipp
In the small test case I included before (and the url above), the block frame is
returning a max element size to the table cell bigger than its desired size. The
table code now prints out a message when this happens.
Priority: P1 → P2
P1 bugs are for crasher bugs, so I've lowered the priority down.
Assignee: kipp → karnaze
I've eliminated as many causes of this problem in the block and inline code as I
could find.

And as a defensive measure, I've added code to the block, inline and container
frame codes so that they are noisy when a child frame *doesn't* provide a

Currently the known two offenders are the ButtonControl code and the ObjectFrame
code. So, since chris owns the form elements I'm giving it to him first and
cc'ing the object frame code owner so that once those are fixed chris can close
the bug.

Chris: the other case I'm seeing is when a table cell has limited the width, yet
the max-element size ends up wider than the given width. I think this can happen
(easily) in over-constrained situations so maybe you need more checks before you
make your debug noise?
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at
Assignee: karnaze → kipp
Severity: major → critical
Priority: P2 → P1
Summary: Layout problem with filled table cells → [CRASH] Layout problem with filled table cells
Target Milestone: M4
This page is now raising an exception (3/16 pm WinNT debug build). Kipp, when
you fix this, please reassign to me.

nsDebug::Assertion(char * 0x006dc324, char * 0x006dc318, char * 0x006dc2dc, int
4124) line 140 + 13 bytes
nsCSSFrameConstructor::CantRenderReplacedElement(nsCSSFrameConstructor * const
0x0131fc50, nsIPresContext * 0x012b91d0, nsIFrame * 0x013975b0) line 4124 + 35
StyleSetImpl::CantRenderReplacedElement(StyleSetImpl * const 0x0131fbc0,
nsIPresContext * 0x012b91d0, nsIFrame * 0x013975b0) line 828
PresShell::HandleCantRenderReplacedElementEvent(nsIFrame * 0x013975b0) line 1297
Assignee: kipp → troy
Assignee: troy → karnaze
It's no longer asserting (it's an assert and not a crash or an exception), so
back to Chris
Severity: critical → normal
Priority: P1 → P3
Summary: [CRASH] Layout problem with filled table cells → Layout problem with filled table cells
Target Milestone: M4 → M5
Removing [CRASH] from summary and downgrading severity.
Target Milestone: M5 → M6
Moving to M6.
Moving to M8.
Moving to M9.
Assignee: karnaze → rods
Target Milestone: M9 → M10
Rod, I am seeing the warnings for combo boxes that Kipp reported in his 3/5
comments. When you fix this please reassign to me to verify the tables are ok.
Assignee: rods → karnaze
I am confused, there is no Combobox on this page, reassigning back to you Chris.
Assignee: karnaze → kipp
Kipp, in the test case in my 2/12 comments, the vertical line corresponding to
the 2nd cell is too wide because the max element size is coming back 60 twips
instead of 15 as it should (since width=1). It looks like there are other
problems with the page as well, so when you fix this, please reassign it back to
me. I'm leaving it as M10, but feel free to change it.

        TR::Rfl en 01756980 rea=0 av=(UC,UC) comp=(UC,UC)
          TC::Rfl 017563A0 rea=0 av=(UC,UC) comp=(2790,3270)
            Area::Rfl en 01756300 rea=0 av=(UC,UC) comp=(UC,UC)
            Area::Rfl ex 01756300 des=(2790,3270) maxElem=(2790,3270)
          TC::Rfl ex 017563A0 des=(2790,3270) maxElem=(2790,3270)
          TC::Rfl 01758AA0 rea=0 av=(UC,UC) comp=(15,UC)
            Area::Rfl en 01758A00 rea=0 av=(UC,UC) comp=(UC,UC)
            Area::Rfl ex 01758A00 des=(75,285) maxElem=(60,285)
          TC::Rfl ex 01758AA0 des=(75,285) maxElem=(60,285)
          TC::Rfl 017593A0 rea=0 av=(UC,UC) comp=(180,UC)
            Area::Rfl en 01759300 rea=0 av=(UC,UC) comp=(UC,UC)
            Area::Rfl ex 01759300 des=(240,285) maxElem=(180,285)
          TC::Rfl ex 017593A0 des=(240,285) maxElem=(180,285)
        TR::Rfl ex 01756980 des=(3105,3270) maxElem=(3030,3270)
Target Milestone: M10 → M14
Target Milestone: M14 → M15
Closed: 20 years ago
Resolution: --- → FIXED
The remaining layout problem was a dup of 4803, which has been fixed. The page
now looks better in gecko than it does in navigator :-)
2/12 test case renders the same in Nav and 5.0. Using 10/20 app, verifying bug
You need to log in before you can comment on or make changes to this bug.