Closed Bug 3094 Opened 26 years ago Closed 25 years ago

Layout problem with filled table cells

Categories

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

Product:
Core
Component:
Layout: Tables
Platform:
x86
Windows 95
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: thefan, Assigned: buster)

References

(
URL
)

Details

Check out my website at the URL above (http://www.ilmfan.com/index2.html). 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. <html> <body> <table border="0" cellspacing="0" cellpadding="0"> <TR> <td width="186" height="218" colspan="5"><a href="http://www.ilmfan.com/how/draco"><img src="http://slip/projects/marvin/bugs/images/draco-ss.jpg" width=186 height=218 border=0></a></TD> <td width="1" rowspan="4" bgcolor="#808080"> <img src="http://slip/projects/marvin/bugs/images/ilm_spacer.gif" width=1 height=1> </TD> <td width=12 rowspan="4" align="LEFT" bgcolor="black"> <img src="http://slip/projects/marvin/bugs/images/ilm_line.gif" width=12 height=1> </TD></TR> </TABLE> </body> </html>
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.
Status: NEW → ASSIGNED
Priority: P1 → P2
P1 bugs are for crasher bugs, so I've lowered the priority down.
Assignee: kipp → karnaze
Status: ASSIGNED → NEW
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 max-element-size. 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 http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
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 bytes 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
Status: NEW → ASSIGNED
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
Status: ASSIGNED → NEW
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.
Status: NEW → ASSIGNED
Assignee: karnaze → kipp
Status: ASSIGNED → NEW
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)
Status: NEW → ASSIGNED
Target Milestone: M10 → M14
Target Milestone: M14 → M15
Status: ASSIGNED → RESOLVED
Closed: 25 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 :-)
Status: RESOLVED → VERIFIED
2/12 test case renders the same in Nav and 5.0. Using 10/20 app, verifying bug fixed.
You need to log in before you can comment on or make changes to this bug.