490177 - Inconsistent table layout inside <svg:foreignObject>

Status: RESOLVED WORKSFORME

(Core :: Layout: Block and Inline, defect)

Description

[Jesse Ruderman]

Attachment: testcase (dynamic)

Based on layout/svg/crashtests/364688-1.svg

Comment 1

[Jesse Ruderman]

Attachment: reference (static)

Comment 2

[Boris Zbarsky [:bzbarsky]]

So what's happening is that the single line inside the block inside that cell is ending up with a different height: 23.6px for the dynamic case vs 22px for the static case.

The difference is due to the height that gets set in nsLineLayout::VerticalAlignLine on the mBounds of the line box.

Comment 3

[Boris Zbarsky [:bzbarsky]]

In the static case, in VerticalAlignLine we have, for |psd|:

  mMinY = -900, 
  mMaxY = 420

In the dynamic case we have:

  mMinY = -1080, 
  mMaxY = 336

Comment 4

[Boris Zbarsky [:bzbarsky]]

Static case:

  [frame]nsTextControlFrame@0x15f94e8: verticalAlignUnit=32 (enum == 11)
     [frame]raw: a=900 h=1320 bp=240,240 logical: h=1320 leading=0 y=-900 minY=-900 maxY=420

Dynamic case:

  [frame]nsTextControlFrame@0x15f94e8: verticalAlignUnit=32 (enum == 11)
     [frame]raw: a=1080 h=1320 bp=240,240 logical: h=1320 leading=0 y=-1080 minY=-1080 maxY=240

So the difference seems to be the ascent the nsTextControlFrame reports.

And that difference comes from the difference in the ascent reported by the scrollframe inside it.  In the static case, it reports 660 twips, but in the dynamic case it reports 840.

And _that_ difference comes back to the box metrics the scrollframe has.  The metrics->mAscent there is different in the two cases.

Comment 5

[Boris Zbarsky [:bzbarsky]]

And the difference _there_ is due to this code in nsFrame::BoxReflow:

6732          if (aDesiredSize.ascent == nsHTMLReflowMetrics::ASK_FOR_BASELINE) {
6733            if (!nsLayoutUtils::GetFirstLineBaseline(this, &metrics->mAscent))
6734              metrics->mAscent = GetBaseline();

The static case returns true from GetFirstLineBaseline.  The dynamic case returns false!

Comment 6

[Boris Zbarsky [:bzbarsky]]

And when it's returning false, here's what the relevant part of the frametree looks like:

                                Block(td)(1)@0x149eca0 {120,120,0,0} [state=00d40421] sc=0x149ea48(i=1,b=0) pst=:-moz-cell-content<
                                  line 0x147ba14: count=1 state=inline,clean,prevmarginclean,not impacted,not wrapped,before:nobr,after:nobr[0x4000] {0,0,0,0} <
                                    nsTextControlFrame@0x149eee8 {0,0,9300,1320} [state=80c45413] [content=0x1cc9c5d0] [sc=0x149edb0]<
                                      HTMLScroll(div)(-1)@0x147c258 [view=0x1cc9dd50] {180,240,8940,840} [state=000c6000] [content=0x1cc9caf0] [sc=0x149f0d4]<
                                        Block(div)(-1)@0x149f4b0 [view=0x1cc9de30] {0,0,8940,840} [state=00d06000] sc=0x149f388(i=0,b=0) pst=:-moz-scrolled-content<
                                        >
                                      >
                                    >
                                  >
                                >

No lines in that innermost div.

And now I know what's going on; we're doing that first reflow before editor init, so there's no text in the text input.  Then we set up the text, but the input's scrollframe is a reflow root, so we don't recompute the baseline for the input itself and don't realign it.  I bet in the static case we don't have a reflow before the editor init.  And since we want to make editor init really lazy, I'm not going to look into that stuff.

The good news is that fixing bug 481751 should fix this.

Comment 7

[Jesse Ruderman]

Works correctly now.