1752237 - Firefox's 9,999 limit on tracks (rows/columns), i.e. max of 10,000 grid-lines, may create interop issues with Chrome, despite being technically allowed by spec

Status: NEW

(Core :: Layout: Grid, enhancement)

Description

[Zhenya Usenko]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:96.0) Gecko/20100101 Firefox/96.0

Steps to reproduce:

https://jsfiddle.net/ZhenyaUsenko/z2hbq45s/13/

Please, look at the example above, it simulates a situation where I was working on an infinite scroll component that displays content only visible at the screen using Grid, in FF rows above 9999 are displayed at exactly 9999 position. This renders as expected in chrome.

Actual results:

Rows above 9999 are displayed at exactly 9999 position

Expected results:

Please remove or extend this limit

Comment 1

[Daniel Holbert [:dholbert]]

Hi! Sorry for the delay here.

The limit you're running up against comes from this code:
https://searchfox.org/mozilla-central/rev/0d11f3660945ce35c49501bb44bc4f82bb2b503c/servo/components/style/values/generics/grid.rs#18-23
which refers to this spec text:
https://www.w3.org/TR/css-grid-2/#overlarge-grids

which allows browsers to limit row numbers as long as "lines at in the range [-10000, 10000]" are accepted. (note that row 9999 ends with line 10000).

So that's what we do. The specific choice of 10000 is ~arbitrary and is just based on this spec requirement. Can you clarify what your use-case is and how many rows/cols you're needing?

("This renders as expected in chrome." -- hmm, I wonder what limit they're using. Presumably they have some limit, but it's just higher?)

Comment 2

[Daniel Holbert [:dholbert]]

(Side note: I marked this as 'confirmed' since it's potentially an interop issue, even though our behavior is technically allowed by the spec. Needs further investigation to see what limits other engines have, and what the costs/benefits might be of hypothetically extending our limits.)

Comment 3

[Zhenya Usenko]

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

(Side note: I marked this as 'confirmed' since it's potentially an interop issue, even though our behavior is technically allowed by the spec. Needs further investigation to see what limits other engines have, and what the costs/benefits might be of hypothetically extending our limits.)

Hi. Please look at the fiddle I posted. There are < 20 grid items displayed and we still hit the limit. I noticed it when I was working on a virtual grid component that displays only those rows visible on screen.

Comment 4

[Zhenya Usenko]

Chrome seems to have a limit of 100000

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Zhenya Usenko from comment #3)

Hi. Please look at the fiddle I posted. There are < 20 grid items displayed and we still hit the limit.

Right -- it's not surprising that we hit the limit (and the number of grid items aren't relevant).

The limit here is on row indexes themselves, and has nothing to do with the number of grid items. Your jsfiddle has items with e.g. grid-row: 9999 through 10010. Firefox is simply clamping the large row indexes so that their ending grid-line is 10,000 (i.e. treating all rows beyond 9999 as being at the slot between row-line 9999 and row-line 10,000). As noted above, this clamping is suggested & allowed by the spec; though we could theoretically relax it (up to a point) if needed.

My question for you (largely out of curiosity) was: what's your use-case for using >10,000 rows (and creating a roughly 280,000px tall grid, in your testcase)? You mentioned a virtual grid component, but that's still quite-large for a UI component. Was this something that's extremely-huge to start with, or something like the twitter waterfall that starts off ~screen-sized and gradually grows over time as data gets loaded in, or something else?

(In reply to Zhenya Usenko from comment #4)

Chrome seems to have a limit of 100000

Do you have a testcase that demonstrates that? I'm seeing different results locally. Though I wonder if maybe there are additional factors beyond raw row count that go into how they limit (if they limit).

Using a modified version of your testcase, I can turn up the row count to over 1,000,000 and they still seem to place the items at distinct positions -- I can load https://jsfiddle.net/uae8sLv2/1 and scroll to the very bottom, and I see 5 distinct bars (at rows 999,998 through 1,000,002).

But 10,000,000 hits some threshold (whether coordinate-space or row-count); I don't see any bars at all at the bottom of https://jsfiddle.net/uae8sLv2/2/ .

Comment 6

[Zhenya Usenko]

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

Using a modified version of your testcase, I can turn up the row count to over 1,000,000 and they still seem to place the items at distinct positions -- I can load https://jsfiddle.net/uae8sLv2/1 and scroll to the very bottom, and I see 5 distinct bars (at rows 999,998 through 1,000,002).

Interesting. It shows 1 bar for me (Linux mint, Chrome 103.0.5060.114)

My question for you (largely out of curiosity) was: what's your use-case for using >10,000 rows (and creating a roughly 280,000px tall grid, in your testcase)? You mentioned a virtual grid component, but that's still quite-large for a UI component. Was this something that's extremely-huge to start with, or something like the twitter waterfall that starts off ~screen-sized and gradually grows over time as data gets loaded in, or something else?

It was not growing. It was max height (to hold all the rows) at the beginning and then you could scroll to whatever position you want and the component would display only those rows visible, similar to react virtualized (http://bvaughn.github.io/react-virtualized/#/components/List). I felt like implementing it with grid-row was the cleanest solution, but unfortunately it didn't work (because of limit), so I ended up using padding even though it was less clean (I needed to calculate padding height manually, for different resolutions, so it was quiet a bit of additional code, that's why I created this issue)

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Zhenya Usenko from comment #6)

(In reply to Daniel Holbert [:dholbert] from comment #5)
Interesting. It shows 1 bar for me (Linux mint, Chrome 103.0.5060.114)

Ah, same for me if I use the same Chrome version (103, current release). v104 beta and v105 dev show 5 distinct bars, though. So this must either be a change they made recently (relaxing/removing their own grid-track count limit), or possibly a change that they're prototyping that's only enabled on beta-and-newer channels.

It was not growing. It was max height [...] but unfortunately it didn't work (because of limit), so I ended up using padding even though it was less clean

Thanks; it's good to have that context.

Comment 8

[Ian Kilpatrick [:iank]]

With GridNG (due to Microsofts work here) we (Blink) initially bumped the limit from 1000, to 100,000. This was possible for us due to how we now store grid repeaters as a compressed representation through the pipeline. See: https://youtu.be/TicsklsAZOE?t=259
In 104/105 we bumped the limit to ~2^32 due to requests from web developers. A data-structure we keep around from legacy grid is currently the active limitation here, and we might need to temporarily bump it down again, I think we shouldn't have any limitation after we remove the legacy code.

Ian

Comment 9

[Daniel Holbert [:dholbert]]

Thanks, Ian! That's very helpful.