Closed Bug 1735375 Opened 4 months ago Closed 3 months ago

fieldset in flex item not fragmented for printing

Categories

(Core :: Layout: Flexbox, defect)

Firefox 93
defect

Tracking

()

VERIFIED FIXED
95 Branch
Tracking Status
firefox95 --- verified

People

(Reporter: jscher2000, Assigned: TYLin)

Details

Attachments

(2 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0

Steps to reproduce:

(1) Open https://www.allrecipes.com/recipe/220867/falafels-with-yogurt-dill-sauce/?printview (from SUMO: https://support.mozilla.org/questions/1353527 )

The ingredient list is a <ul> in a <fieldset> in a <section> in a flex item.

(2) Call up Print to display preview

Actual results:

The list is pushed from the first page to the second page.

On the second page, it is truncated due to limitations of the layout, but this is not the main issue.

Same on Nightly 20211012093200

Expected results:

The <fieldset> inside a flex item should fragment, as it does outside of a flex item after bug 471015.

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Flexbox' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Layout: Flexbox
Product: Firefox → Core

I got this when choosing "Font Size: Large", then print. The "ingredient" list is shifted to the second page, and is truncated.

Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: nobody → aethanyc
Status: NEW → ASSIGNED

(I just found that I haven't sent the comment ...)

When a flex container is in a fragmented context, it can reflow a flex item twice: the first time is a measuring reflow to compute a flex item's total block-size without any constraint in the block axis; the second time is a final reflow with available block-size applied.

The reported site uses a <fieldset> in a flex item. When the flex item is under the final reflow, according to the following if, we skip reflowing its child <fieldset>'s inner frame because <fieldset> doesn't have any condition to let aReflowInput.ShouldReflowAllKids() returns true, nor does its next-in-flow exists (yet).

  if (aReflowInput.ShouldReflowAllKids() || GetNextInFlow()) {
    reflowInner = inner != nullptr;
    reflowLegend = legend != nullptr;
  }

https://searchfox.org/mozilla-central/rev/d37daf2f82ed22b6a2a5cbbb975423825dfd69fa/layout/forms/nsFieldSetFrame.cpp#429

However, we really should reflow the inner frame of the fieldset because the available block-size is constrained this time where it was unconstrained in the last reflow.

Pushed by aethanyc@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/6728f6569a32
Always reflow fieldset when its available bsize is constrained. r=dholbert
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 95 Branch
Flags: qe-verify+

Reproduced this issue using an affected Nightly build 95.0a1 (20211012093200) on Win 10x64 and Ubuntu 20.04.

Verified as fixed on Beta 95.0b2 (20211102190739) on Win 10x64, macoS 10.15 and Ubuntu 20.04.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.