1989365 - Resolve 'stretch' and '-webkit-fill-available' against the viewport height in quirks mode (as we do with percentages)

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

STR:

1. Load attached testcase (with layout.css.stretch-size-keyword.enabled set to true, so that the second box's styling is recognized)

EXPECTED RESULTS:
All three boxes should fill the viewport height.

ACTUAL RESULTS:
Only the first box fills the viewport height.

This is the reason that bug 1886566 is broken even with -webkit-fill-available support preffed on (per bug 1886566 comment 7).

Probably need to fix this soon, otherwise bug 1988938 might result in regressions for sites that do something like this in quirks mode:

height: 100%;
height: -webkit-fill-available;

...where previously we'd honor 100% and now we'd honor (but not grow) -webkit-fill-available.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (standards mode) - Firefox/Chrome agree not to expand in this case

Just to illustrate that this is specific to quirks-mode: here's a testcase just like the previous one where I've simply declared a DOCTYPE to trigger standards-mode.

In this case, we get consistent behavior (and Chrome agrees with us); none of the boxes should expand to fill the viewport.

Comment 2

[Daniel Holbert [:dholbert]]

WebKit behavior:

• They don't yet implement stretch, so the stretch parts of the tests are irrelevant (it just falls back to initial height:auto and shrinks-to-fit).
• On testcase 1, they fill the viewport height for -webkit-fill-available (matching Chrome and matching the consensus height:100% behavior).
• On testcase 2, they also fill the viewport height for -webkit-fill-available, which is different from how they handle height:100% in this testcase (that one does not fill the viewport) and different from Chrome's -webkit-fill-available section in this testcase (which does not fill the viewport)

I think WebKit's implementation of -webkit-fill-available is just a bit more quirky here (even in standards mode); we should treat Chrome's as more sensible to match here (particularly given that it's consistent with 100%).

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 3

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: reference case 3 (with `height:100vh` on body)

Comment 5

[Daniel Holbert [:dholbert]]

This isn't entirely a regression since it's just a bug in a newly-enabled feature, but it'll likely manifest as a regression in certain sites if we ship without fixing it, for cases where a site has height:100%; height: -webkit-fill-available and we go from honoring the first one (and growing) to honoring the second (and not-growing).

Hence, marking as a regression, in part to help keep this from slipping off the radar before 145 ships. Hoping to set aside some time to investigate/fix soon and uplift to 145 (which will be in beta as of a few days from now).

Comment 6

[Pascal Chevrel:pascalc]

Tracking for a potential uplift in beta

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The bug is marked as tracked for firefox145 (beta). However, the bug still has low severity.

:fgriffith, could you please increase the severity for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 8

[Frank Griffith Jr]

@dholbert Are we still good with this closing in time for 145 uplift?

Comment 9

[Daniel Holbert [:dholbert]]

Yup, I'm planning to work on it and have it nominated for uplift by later this week. (If for some reason we're unable to uplift this, the alternative would be to uplift a pref-flip to revert bug 1988938 for the 145 train.)

Comment 10

[Frank Griffith Jr]

Thanks. Will advise if we have other questions from REO Triage

Comment 11

[Daniel Holbert [:dholbert]]

We switched this feature off on beta145 (bug 1988938 comment 18), so there's no need to track for that release anymore.

Comment 12

[Daniel Holbert [:dholbert]]

Attachment: testcase 4 (testing a different quirky percent resolution behavior)

Note, there's a different quirks-mode behavior that we don't need to bother specially handling for stretch/-webkit-fill-available at this point -- the "percent resolves against fixed-height ancestor" quirk.

Here's a testcase that exercises that -- the first colorful div has a percentage (which Firefox and Chrome resolves), and the second and third div have -webkit-fill-available and stretch (which Firefox and Chrome do not resolve).

(Safari actually does resolve -webkit-fill-available here, but I lean towards not doing that, since we're trying to purge quirks from this keyword as we ship the modern standardized version.)

Comment 13

[Daniel Holbert [:dholbert]]

Attachment: Bug 1989365: Treat 'height:stretch' (and aliases) as able to resolve against quirks-mode body height. r?TYLin,#layout

This patch lets 'stretch' block-sizes get opted in so they can resolve against
the result of CalcQuirkContainingBlockHeight(). That's where we handle the
"html element fills the viewport" and "body element fills the html element"
quirks-mode behaviors explained here:
https://quirks.spec.whatwg.org/#the-html-element-fills-the-viewport-quirk
https://quirks.spec.whatwg.org/#the-body-element-fills-the-html-element-quirk

This makes us match the behavior that other browsers have been shipping (with
'stretch' in Chrome as well as its '-webkit-fill-available' alias in Chrome and
Safari), and we're aware of at least one site that depends on this behavior
(tracked in bug 1886566).

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/139b833802a0
https://hg.mozilla.org/integration/autoland/rev/2cb11aff2f45
Treat 'height:stretch' (and aliases) as able to resolve against quirks-mode body height. r=TYLin,layout-reviewers

Comment 15

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/56133 for changes under testing/web-platform/tests

Comment 16

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/2cb11aff2f45

Comment 17

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: This fixes a correctness bug with the '-webkit-fill-available' sizing keyword, which is riding the trains as part of the release that's currently on beta.

If left unfixed, the correctness bug could potentially cause site breakage, for sites that have CSS similar to what's quoted at the end of https://bugzilla.mozilla.org/show_bug.cgi?id=1989365#c0 .

• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Load the attached 'testcase 3', https://bug1989365.bmoattachments.org/attachment.cgi?id=9519409. Expected results are for all the blue boxes to be about as tall as your viewport (matching Chrome). Buggy results are for the blue boxes to be short (sized-to-content)
• Risk associated with taking this patch: low
• Explanation of risk level: This patch is extremely small and targeted -- just opting in a newly-supported keyword to an existing quirks-mode sizing behavior, to match other browsers.
• String changes made/needed: None.
• Is Android affected?: yes

Comment 18

[Daniel Holbert [:dholbert]]

Attachment: Bug 1989365: Treat 'height:stretch' (and aliases) as able to resolve against quirks-mode body height.

This patch lets 'stretch' block-sizes get opted in so they can resolve against
the result of CalcQuirkContainingBlockHeight(). That's where we handle the
"html element fills the viewport" and "body element fills the html element"
quirks-mode behaviors explained here:
https://quirks.spec.whatwg.org/#the-html-element-fills-the-viewport-quirk
https://quirks.spec.whatwg.org/#the-body-element-fills-the-html-element-quirk

This makes us match the behavior that other browsers have been shipping (with
'stretch' in Chrome as well as its '-webkit-fill-available' alias in Chrome and
Safari), and we're aware of at least one site that depends on this behavior
(tracked in bug 1886566).

Original Revision: https://phabricator.services.mozilla.com/D273323

Comment 19

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 20

[Ciprian Georgiu, Desktop QA]

I've repro this issue with STR from comment 0 using an affected Nightly build (2025-09-18) running Win 11.

The issue is verified as fixed on latest Nightly 147.0a1 under macOS 28, Win 11 and Ubuntu 24.

Comment 21

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/1d63fb1b61ef
https://hg.mozilla.org/releases/mozilla-beta/rev/19ee5ecdc38f

Comment 22

[Ciprian Georgiu, Desktop QA]

This is also verified as fixed on Firefox 146.0-build2 under Win 11, macOS 26 and Ubuntu 24.