It still jumps around if you hold and drag the scrollbar - always my complaint with these.
With on-demand loading you would set the virtual height of the scrollable area to the height necessary to show all (or a huge chunk of) your data, and then page in chunks of the data as it approaches the viewport.
Then dragging the scrollbar works, and touch scrolling shows a reasonable representation of how much data is left.
Of course if you actually advanced extremely far in a typical "infinite" scrolling view, the scrollbar would similarly become pretty useless, but in practice very few people actually scroll all that far, so it seems better to optimize for that case.
They could meet halfway by making the "scrollbar readjustment" chunk size somewhat larger than the "load new data" chunk size, so you get the on-demand loading efficiency of the latter with fewer scroll-bar jumps, but I don't think they could make the former too large without creating more usage problems than they're solving.
I've done many user tests and training sessions only to inwardly wince every time the user painstakingly does that. (And this on their own hardware, with their own mouse they use every day at work.)
After you explain it, they say "wow, that's neat." And then promptly forget it and start dragging the scrollbar again.
I've been surprised to find that dragging an old-fashioned scroll bar is actually a faster and more accurate than the wheel if you're scrolling by more than a page or so.
When viewing your music library, the scroll bar grabber would be the correct size for how many items were in your library so grabbing it and scrolling would work right. It didn't load all X number of items you had at a time though either.
Win32: http://msdn.microsoft.com/en-us/library/windows/desktop/ms64...
IIRC it isn't exposed to JS except maybe for some new fullscreen API (not my area, sorry.)
Unfortunately this is rarely the case, with a few exceptions, e.g. a spreadsheet, where you know everything upfront.