[Webkit-unassigned] [Bug 195158] New: Maximum element size is too restrictive for virtual scrolling

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=195158

            Bug ID: 195158
           Summary: Maximum element size is too restrictive for virtual
                    scrolling
           Product: WebKit
           Version: Safari Technology Preview
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Layout and Rendering
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: andyearnshaw at gmail.com
                CC: bfulgham at webkit.org, simon.fraser at apple.com,
                    zalan at apple.com

We are using a common technique for virtual scrolling in a list (1-dimensional) and a grid (2-dimensional). The technique involves using a container element of fixed dimensions, with a child that is the size of the area you want to scroll, then the element that updates as you scroll sticky-positioned to the maximum size of the container.

Here's a rudimentary example:

https://jsfiddle.net/AndyE/2ev53nuq/56/

This works well, until you have customers with over 10 million items in a list, and those are transposed into columns on a grid.

Safari tops out at 33,554,428px for the width, height, scrollWidth or scrollHeight of an element. This limits us to 838,860 rows at the 40 pixels per row given in the example. If you update the jsfiddle example to display more than that, Safari caps to that maximum height. If the list items are transposed into column labels, then the displayable amount reduces drastically.

Naturally, our product has searching and filtering to provide more sensible navigation of large datasets. However, we still want this to work as expected if we scroll the user to a section of the grid or list based on their search results. About 64 of our customer's lists have more than 10 million items, about 470 have between 1 and 10 million and there are about 35,000 lists in total.

At the moment, we're using a custom scrollbar, but this gets too complex as you try to match the features and styling of native scrollbars.

I have heard, anecdotally whilst chasing people in my company and asking them, that we have a customer with a list of 35 million items. To virtually scroll over that many items in columns, at an average of 250px per column, we would need a scrollWidth of nearly 9 billion pixels, more than 500 times the current maximum in Firefox and almost 270 times the maximum in Safari/Chrome.

My preference is that the standards provide a better way of having virtual scrollbars than resorting to jumping through hoops like creating ridiculously large elements; I have proposed a CSSOM feature[1] and attempted to start a discussion around web components[2]. In the latter ticket, Domenic Denicola from the Google Chrome team recommended I file tickets with the major browsers to see if I could get the limits increased instead, and this is what I am doing as an interim solution.

[1]: https://github.com/w3c/csswg-drafts/issues/3397
[2]: https://github.com/w3c/webcomponents/issues/791

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190228/86c76983/attachment.html>