1872755 - Consider supporting `-webkit-fill-available` as an alias for `-moz-available` (extended to work in the height axis)

Status: ASSIGNED

(Core :: CSS Parsing and Computation, defect)

Description

[Daniel Holbert [:dholbert]]

We've apparently got some sites that rely on width:-webkit-fill-available for proper layout, and are broken in Firefox as a result.

Example: https://github.com/webcompat/web-bugs/issues/115962#issuecomment-1871236155

This is roughly equivalent to -moz-available. Perhaps we should just implement it as an alias for -moz-available?

Comment 1

[Daniel Holbert [:dholbert]]

Here's a testcase:

data:text/html,<div style="width:20px; overflow:clip; width: -webkit-fill-available;">CanYouSeeMe

Firefox just renders 20px of the text and clips the rest (dutifully honoring the CSS that it understands).

(If you manually swap in -moz-available into that data URI, then we show all of the text.)

Comment 2

[Daniel Holbert [:dholbert]]

[Transferring WebCompat Priority: P2 from bug 1495868 to this bug here, since the aliasing that's proposed in this bug here seems to be the remaining webcompat-relevant work that's covered in bug 1495868.]

Comment 3

[Daniel Holbert [:dholbert]]

Bad news: in bug 1891380 at least, it seems our -moz-available isn't enough like -webkit-available where aliasing would help. In that bug, height:-moz-available collapses to 0 height, whereas height:-webkit-available (in Chrome) expands to fill the viewport.

Comment 4

[Daniel Holbert [:dholbert]]

It looks like, in Chrome/WebKit, height:-webkit-available specifically works on elements that are position:absolute or fixed. But it behaves like height:auto on in-flow content, I think.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: testcase 1, testing `-moz-available` and `-webkit-fill-available` for both `width` and `height` on abspos element

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: testcase 2, testing `-moz-available` and `-webkit-fill-available` for both `width` and `height` on an in-flow element with a definite-size containing block

er, I guess the relevant condition is just whether or not the containing block has a definite height, i.e. whether a percent height would have resolved. Here's an example where this works in Chrome, with in-flow content. (Notably, this results in overflow here, because the height value resolves to the height that would fill the container's available space; though in this case there's other siblings preceeding this element, which pushes it downwards.)

Chrome's behavior seems probably-correct for the definition of stretch in the spec, here:
https://drafts.csswg.org/css-sizing-4/#stretch-fit-sizing
...so it probably makes sense to modify -moz-available to match Chrome's behavior on these heights, in the interests of eventually supporting the stretch keyword for height/width and having -moz-available be an alias for that, per bug 1495868.

Comment 7

[Daniel Holbert [:dholbert]]

I guess the compat issue discussed in comment 3 - comment 6 is tracked in bug 527285.

Comment 8

[Calin Tanase]

This is still an issue based on: https://github.com/webcompat/web-bugs/issues/115962

Environment:
OS: Windows 10
Browsers tested: Firefox Nightly 128.0a1 (2024-05-30) / Firefox Release 126 / Chrome 125.0.6422.113

Comment 9

[Daniel Holbert [:dholbert]]

Here's my tentative plan here, at the moment -- I'm imagining three distinct phases, landing in the order described below, to address the existing webcompat breakage while being cautious about possible follow-on regressions:

(1) bug 1872755 [this bug]: add support for -webkit-fill-available as a new keyword, sharing some code with -moz-available, but extended to work in the height axis (where -moz-available would still do nothing per bug 527285).
(2) bug 1789477: Add support for the stretch keyword as the official name for the -webkit-fill-available behavior from (1), with -webkit-fill-available changing to be an alias (which I think is what Chrome is also planning on doing).
(3) bug 527285: Adjust -moz-available to also be an alias for stretch so that all three keywords do the same thing.

Part (1) should directly address the various -webkit-fill-available bugs, with as-small-as-possible chance for site-breakage/regressions.

Part (2) adds the standards-based keyword for that behavior; and part (3) will help us modernize -moz-available and remove special-case/legacy codepaths. It's possible that parts (2) or (3) might trigger regressions in cases where sites happen to accidentally have fragile dependencies on these keywords not-working (behaving as auto or being ignored) in certain contexts; if we run into that sort of breakage, we could always backout or slow-rollout these parts as-needed while we address breakage, without needing to slow our deployment of Part (1).

Comment 10

[Daniel Holbert [:dholbert]]

(And I'll use this bug here to cover "Part (1)" from that plan. Parts (2) and (3) happen in separate bugs [now linked above] and don't have any need to land in the same timeframe as Part (1) or as each other.)

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: WIP: Bug 1872755: Handle 'stretch' and '-webkit-fill-available' as block-sizes, in nsIFrame::ComputeSize.

This fixes the LinkedIn bug and also the gracobaby.ca bug, if you enable the
layout.css.webkit-fill-available.enabled about:config pref (added in an earlier
patch in this series).

Comment 12

[Daniel Holbert [:dholbert]]

intent to prototype: https://groups.google.com/a/mozilla.org/g/dev-platform/c/-pMSV-kgUjA

Comment 13

[Phabricator Automation]

Comment on attachment 9414790 [details]
WIP: Bug 1872755: Handle 'stretch' and '-webkit-fill-available' as block-sizes, in nsIFrame::ComputeSize.

Revision D217688 was moved to bug 1933408. Setting attachment 9414790 [details] to obsolete.

Comment 14

[Daniel Holbert [:dholbert]]

[adding platform-scheduled:2025-03-31 to mark this as scheduled-to-be-completed-during-Q1, though most likely it'll be completed on Nightly pretty soon. I've got a patch in my local repo with some necessary fixes that I need to finish off and land, and then I think we can enable this pref on Nightly and let it ride the trains. I've just been focused on interop-2025-related stuff and other catchup tasks since coming back from holiday break.]

Comment 15

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #14)

[adding platform-scheduled:2025-03-31 to mark this as scheduled-to-be-completed-during-Q1

[pushing date out a bit; didn't finish this off yet, but still planning to do so soon]

Comment 16

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #15)

[pushing date out a bit; didn't finish this off yet, but still planning to do so soon]

[Sorry for churn -- I ended up taking bug 1935269 and associated work first, so pushing this date out a bit again.]

Comment 17

[Daniel Holbert [:dholbert]]

Updated plan here:
A) bug 1988301: Add an additional pref to prevent us from accepting -webkit-fill-available in properties beyond width and height (that's where we see it the most, and where I think we've got robust support)
B) bug 1988938: Land a pref-flip to enable layout.css.webkit-fill-available.enabled to enable support (in width and height)
[these^ address most of the webcompat pain here]
C) bug [to be filed]: Finish making the keyword robust in other properties.
D) bug 1989071: Enable the pref that we added in (A) to fully-support the keyword, addressing remaining webcompat pain.
E) bug 1989073: Clean up the now-unnecessary shim code added in (A)

Comment 18

[Daniel Holbert [:dholbert]]

(planning on finishing (A) and (B) within the next day or so; the rest is hopefully doable next week; but in any case (A) and (B) will get us to a much better place)

Comment 19

[Daniel Holbert [:dholbert]]

Per bug 1988938 comment 7, I'm moving some dependencies from this bug to that bug, specifically the dependencies that are fixed by the pref-flip that I just landed there (which as noted in comment 17 is most of the webcompat pain here)

Comment 20

[Daniel Holbert [:dholbert]]

And I'm going to move most other bugs to hang off of bug 1989071 (which is where we'll enable the secondary pref to support this keyword in other properties like {min,max}-{height,width}).

Comment 21

[Daniel Holbert [:dholbert]]

(removing https://webcompat.com/issues/115962 from see-also since it's tracked by bug 1872785 and it stopped reproducing after a site redesign)

Comment 22

[Oriol Brufau [:Oriol]]

Blink successfully aliased -webkit-fill-available to stretch.