Closed Bug 13553 Opened 25 years ago Closed 24 years ago

Table doesn't render properly

Categories

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

defect

Tracking

()

VERIFIED FIXED
mozilla0.8

People

(Reporter: beard, Assigned: buster)

References

()

Details

(Whiteboard: [TESTCASE])

Attachments

(3 files)

Run viewer or appRunner, and the table on the right, labeled "The Shit" doesn't
render completely (it's cut off on the left side).
Attached file testcase
Whiteboard: [TESTCASE]
Bug also occurs in apprunner 1999-09-10-10-M11 on Windows NT 4.0 SP5.
The bug is caused by a <P> without an end-tag. Could be a Parser thing.
Hardware: Macintosh → All
Assignee: karnaze → kipp
Kipp, the area frame of the cell in the top most table is reporting a max
element width of 0 even though the nested table is reporting a max element width
of 2400.

          TC::Rfl 01756050 rea=0 av=(UC,UC) comp=(2070,UC)
            Area::Rfl en 01757CA0 rea=0 av=(UC,UC) comp=(UC,UC)
              TO::Rfl en 017586B0 rea=0 av=(UC,UC) comp=(2400,UC)
              TO::Rfl ex 017586B0 des=(2400,375) maxElem=(2400,0)
            Area::Rfl ex 01757CA0 des=(UC,375) maxElem=(0,0)
          TC::Rfl ex 01756050 des=(UC,435) maxElem=(75,0)
Status: NEW → ASSIGNED
Target Milestone: M14
The interior right aligned floating tables were mucking up the size of the outer
tables table cell. Now they don't.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Using 9/28 Apprunner, looks okay to me. Verifying bug fixed.
This has somehow regressed. I found this testcase during my regression tests for
61772. The patch attached there fixes this bug.
Status: VERIFIED → REOPENED
Keywords: mozilla0.8
Resolution: FIXED → ---
*** Bug 61772 has been marked as a duplicate of this bug. ***
Since I reported bug 61772, and it is now labeled a duplicate of this one, I am
cc'ing myself on this one.
Blocks: 63457
Chris - there is a patch attached to bug 63457 that fixes this bug.  Could you
have a look?
Keywords: patch
*** Bug 64193 has been marked as a duplicate of this bug. ***
seeing this on Win2k too...
OS: Mac System 8.5 → All
On linux, the patch from 61772 makes things MUCH better.  I've been reluctantly
using 4.7 a lot because of this bug (images not visible on many pages) and am
eagerly looking forward to the patch.
sounds like this clears up lots of problems, so I'm bumping up the priority.  I
will review the change over the weekend, hopefully get it in early next week.
Severity: normal → major
Status: REOPENED → ASSIGNED
Priority: P3 → P2
Target Milestone: M14 → mozilla0.8
patch looks great.  running block regression tests now, expect to check in soon.
Blocks: 59087
I've had this running in my tree for a while, it looks good.  Also, it seems to
pass all the layout and table regression tests.  Well done.

sr=buster

Bernd:  do you have check-in permission, or would you like me to check this in
for you?
I'll check this in soon.
Whiteboard: [TESTCASE] → [TESTCASE] [fix in hand]
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 25 years ago24 years ago
Keywords: patch
Resolution: --- → FIXED
Whiteboard: [TESTCASE] [fix in hand] → [TESTCASE]
This has regressed in my CVS build from 1/24/01.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Dan:  please be more specific.  In what way has it regressed?  Which test case
isn't working for you? On what platform?  Thanks.
Buster, see

http://www.pipebombnews.com/

This is the site I originally cited in bug 61772.  I will also attach the
minimized testcase that was developed from it for you to see.  The patch that
was checked in to fix this fixed that particular problem (for me, anyway)... 
But now it seems to be back.  My platform is Intel Linux. :-)  Let me know if
you need any other details.
I hate regressions.
I hate them especially when they break my patch.
mcafee@netscape.com has backed  out my patch on 01/24/2001 18:57.
ok, I see it now.  When mcafee backed out pierre's changes, the fix I checked
in for this bug got backed out as well.  Why?  What other changes were
accidentally, or at least silently, wiped out by this change, I wonder?
Status: REOPENED → ASSIGNED
I helped McAfee with that backout - sorry your patch was backed out as well, but
please understand that it was a huge and heinous task backing out 64 files and
verifying that it worked correctly. We checked several of the files for
post-Pierre checkins, but there we 64 files so we didn't check them all.
Fortunately, this patch looks like it will be easy to reapply. My apologies for
the mistake - let me know if you want me to reapply the patch for you.
I'm happy to check the patch back in, and yes it is easy.  I'm not particularly
upset, I just felt like I needed to raise the flag in case this wasn't the only
one you missed.  Our regression testing (not just layout, but mozilla's) isn't
yet sophisticated enough to catch these sorts of mistakes.  So it's a tough
manual process, at this point.
I'll post a reminder to the layout and checkins newsgroups so anyone who is not
alerady aware of the backout can doiuble-check that their changes are OK - thanks.
Was bug 66508 caused by the back outs fiasco happened here?
Current Mac builds are unusable.
I checked the patch in a few minutes ago -- it should be in again in this
evening's builds (not this morning's, though).

I also checked the backout by backing out the backout and then backing out
pierre's changes (see my post to mozilla-layout).  nsBlockFrame.cpp was the
only file showing changes.  It's not clear to me how this happened.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
IE and Moz now look identical...
Status: RESOLVED → VERIFIED
Keywords: mozilla0.8
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: