Open Bug 1605868 Opened 3 years ago Updated 2 months ago

Height of textarea inside table with percentage height changed after bug 1351924

Categories

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

defect

Tracking

()

People

(Reporter: emilio, Unassigned, NeedInfo)

References

(Regression)

Details

(Keywords: regression)

See bug 1598458 comment 7 for a test-case that changed behavior (that is, https://bugzilla.mozilla.org/attachment.cgi?id=9117661).

David, do you think you'll have some time to look into this?

Flags: needinfo?(dbaron)

The behavior change in question is that:

  • before the regression, the testcase had two textareas, the first about 25% height and the second about 75% height (adding to just over 100%).
  • after the regression, the second textarea instead became roughly the height of just under 3 lines of text

Post-regression, the div containing the textarea (which has display: table-cell) still has the expected height; it's just the textarea inside it that's smaller.

Somewhat to my surprise, we only hit this code for the first table cell (twice) but not for the second one. We also only ever set the NS_TABLE_CELL_HAD_SPECIAL_REFLOW flag for the first table cell, but not the second (based on a frame dump after the reflow), which is a little surprising to me. I need to look into what made this work before...

I think the underlying problem here is that:

  • I think there's a behavior where children of table cells honor percentage heights in more cases than other things (i.e., even when the cell is auto-height (and the row too, even)), though I can't currently find the code for it
  • if that's the case, then mFlags.mIsBResizeForPercentages needs to be set to true for table cells whenever IsBResize(). (I think this code should then propagate it to the anonymous block inside the cell.)

But I want to actually find the code for the first point to check that it does what I think it does... (Probably another time; dinner soon.)

So I think this code is what I was thinking of... but I also think this may not be a regression from the part of the regressing bug that I was thinking it was, given that adding:

  if (IsBResize()) { 
    mFlags.mIsBResizeForPercentages = true;
  }

doesn't fix the bug.

So it might actually be a regression from some of the other cleanup.

Yeah, this is related to this code removal; if I add:

  if (mCBReflowInput && !mFrame->IsBlockFrameOrSubclass() && mCBReflowInput->IsBResizeForWM(wm)) {
    SetBResize(true);
    mFlags.mIsBResizeForPercentages = true;
  }

then that does make this bug go away. So I think this is about either the row or the cell optimizing away reflows.

The minimal variant of the above that makes this bug go away is actually:

  if (mCBReflowInput && mFrame->IsTableRowGroupFrame() && mCBReflowInput->IsBResizeForWM(wm)) {
    SetBResize(true);
    mFlags.mIsBResizeForPercentages = true;
  }

so, a little to my surprise, it's about the flags on the row group. (Both rows are within the same row group; I checked!)

Priority: -- → P3

(In reply to David Baron :dbaron: 🇪🇸 ⌚UTC+1 from comment #6)

so, a little to my surprise, it's about the flags on the row group. (Both rows are within the same row group; I checked!)

Can you suggest simple solution from CSS side?
I have broken product, because of this bug. Based on bug priority faster make fix from my side. But I want to fix it without change HTML.

thank you.

Has Regression Range: --- → yes
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.