[css-grid-2] Resolving padding in indefinite intrinsic size calculation and using that to resolve indefinite size?

Spec

I'm looking at grid-auto-repeat-max-size-001.html in order to fix this Compat 2023 bug in Chromium

...however, it appears that both Blink and WebKit make more sense to me than what Gecko is doing, although Gecko's behavior is marked as passing.

Note that this is in relation to sub-cases 16 and 19, which Blink and WebKit are marked as failing and Gecko is marked as passing. The other cases are all in agreement.

I'll explain what Blink and WebKit are doing, and why I think that is the proper behavior.

No width or height are specified on the grid, so for sizing purposes, we fall back to the default intrinsic size of 300px by 150px. However, with this fallback, we are able to determine a final size of the grid by the end of the grid layout algorithm that differs from 300px by 150px.

Padding is 10%, on an indefinite inline axis, which falls back to 300px, so we land at 30px padding. This is agreed upon in all implementations.

Grid-template is set to repeat(auto-fill, 50px) / repeat(auto-fill, 100px); which we can resolve to two repetitions in both directions to fill the indefinite 300px width and 150px indefinite height (it can't be 3 repetitions in either axis due to the padding). This is also agreed upon in all implementations.

This is where things diverge in Gecko. For the inline size, Blink/Webkit add up the 30px padding on each side, along with 2 repetitions of 100px for each column, and land at 260px. Gecko sticks with the default 300px intrinsic size, even though it is possible to calculate an intrinsic size based on the fixed column sizes. There seems to be some extra padding after the grid items in Gecko, which is how it lands at 300px. I can't find any reference to this in the grid spec.

For block size, interestingly, Blink/WebKit/Gecko all agree on adding up padding-top and padding-bottom (30px + 30px) along with two rows of 50px, landing at 160px.

It's not clear to my why Gecko is inconsistent between the inline and block direction here. The grid spec implies that if fixed sizes are specified on track sizes (as is happening here), that those will be used for intrinsic size calculation.

If there is something I'm missing here, and that Gecko is indeed doing this correctly, I'd be happy to update Chromium's implementation. Otherwise, I'll update the expected sizes in the test case.

@bfgeek created a reduced case that demonstrates the extra padding Gecko is adding: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=11785

Start with the CSS Grid intrinsic-sizes specification and WPT case grid-auto-repeat-max-size-001.html, focusing on sub-cases 16 and 19. Compare the inline and block intrinsic-size calculations across Gecko, Blink, and WebKit, using the linked reduced case to inspect the extra padding. Done means establishing the spec-consistent behavior and determining whether the test expectations or an implementation should change.