Closed Bug 26184 Opened 25 years ago Closed 25 years ago

block code reflows nested floating table with 0 mComputedWidth

Categories

(Core :: Layout, defect, P1)

Product:
Core
Component:
Layout
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: karnaze, Assigned: troy)

References

(
URL
)

Details

The block containing the nested table is incorrectly reflowing it with an 
mComputedWidth=0. This causes the nested table to take its minimum width. This 
probably affects a lot of pages.

<table border="3">
 <tr>
  <td>
   <table border="3" align="left" width=50%>
    <tr>
     <td>
      blah blah blah blah blah blah blah blah blah blah blah blah blah
      blah blah blah blah blah blah blah blah blah blah blah blah blah
      blah blah blah blah blah blah blah blah blah blah blah blah blah
      blah blah blah blah blah blah blah blah blah blah blah blah blah
      blah blah blah blah blah blah blah blah blah blah blah blah blah
     </td>
    </tr>
   </table>
  </td>
 </tr>
</table>

  TO::Rfl en 0205038C rea=0 av=(8940,UC) comp=(8850,UC) count=148
    T::Rfl en 020503E0 rea=0 av=(8940,UC) comp=(8850,UC) count=149
      TRG::Rfl 0205044C rea=0 av=(UC,UC) comp=(UC,UC) count=150
        TR::Rfl en 0205048C rea=0 av=(UC,UC) comp=(UC,UC) count=151
          TC::Rfl 020504D4 rea=0 av=(UC,UC) comp=(UC,UC) count=152
            Area::Rfl en 02050530 rea=0 av=(UC,UC) comp=(UC,UC) count=153
            TO::Rfl en 020505B4 rea=0 av=(UC,UC) comp=(0,UC) count=154
              T::Rfl en 02050608 rea=0 av=(UC,UC) comp=(0,UC) count=155
                TRG::Rfl 02050674 rea=0 av=(UC,UC) comp=(UC,UC) count=156
                  TR::Rfl en 020506B4 rea=0 av=(UC,UC) comp=(UC,UC) count=157
                    TC::Rfl 020506FC rea=0 av=(UC,UC) comp=(UC,UC) count=158
                      Area::Rfl en 02050758 rea=0 av=(UC,UC) comp=(UC,UC) count=
159
                      Area::Rfl ex 02050758 des=(28215,285) maxElem=(375,285)
                    TC::Rfl ex 020506FC des=(28275,345) maxElem=(435,345)
                  TR::Rfl ex 020506B4 des=(28335,405) maxElem=(435,345)
                TRG::Rfl ex 02050674 des=(UC,405) maxElem=(435,345)
                TRG::Rfl 02050674 rea=2 av=(495,UC) comp=(495,UC) count=160
                  TR::Rfl en 020506B4 rea=2 av=(495,UC) comp=(495,UC) count=161

                    TC::Rfl 020506FC rea=2 av=(435,UC) comp=(375,UC) count=162
                      Area::Rfl en 02050758 rea=2 av=(375,UC) comp=(375,UC) coun
t=163
                      Area::Rfl ex 02050758 des=(375,18525)
                    TC::Rfl ex 020506FC des=(435,18585)
                  TR::Rfl ex 020506B4 des=(465,18645)
                TRG::Rfl ex 02050674 des=(495,18645)
              T::Rfl ex 02050608 des=(585,18735) maxElem=(585,0)
            TO::Rfl ex 020505B4 des=(585,18735) maxElem=(585,0)
            Area::Rfl ex 02050530 des=(645,18735) maxElem=(585,0)
          TC::Rfl ex 020504D4 des=(705,18795) maxElem=(645,0)
        TR::Rfl ex 0205048C des=(765,18855) maxElem=(645,0)
      TRG::Rfl ex 0205044C des=(UC,18855) maxElem=(645,0)
do we know when this was introduced?
Priority: P3 → P1
Target Milestone: M14
No. In addition to running the tests on changes I made, I used to run them every 
time I updated from the tree and would have some idea when these kinds of 
regressions happened. Because this is very time consuming (and in some cases 
impossible when major changes occur like scrolling), I haven't been doing it 
regularly, relying on others to ensure non-regressions instead.
Re-assigning to me
Assignee: kipp → troy
Fixed by change to nsHTMLReflowState code
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Marking verified fixed based on the last comments.

Marking verified fixed based on the last comments.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.