Thanks a lot for sharing that. So my simple summary of that (in reference to my objective above of locking out scrolling) would be:
- Instead of the editor owning its scrollbar, its scrollbar is removed and replaced with two separate divs for the vertical and horizontal scrollbar respectively
- Any scroll events on these “fake” scrollbars are propagated to the editor div
- Any scroll events on the editor div directly still move the editor div but are also propagated to the fake scrollbars
As a result, it’s quite easy to hide the scrollbars but not easy at all to hijack scroll behavior, not least because scroll events trigger after scrolling has already occurred.
So to intentionally freeze all scrolling, one approach I can see (without having to monkey patch the event listeners) would be to intercept all scroll events on the editor itself.
Put an opacity: 0 overlay div over the editor. This would work and probably be very simple, however, it would also prevent users from selecting test or otherwise interacting with the editor. I’ve done some simple tests and this does seem to work.
Place a touch-action: none on key elements. Now, I tried placing that on a bunch of parent divs for the editor as well as the main editor div itself but wasn’t able to quite intercept all the scroll actions. Do you think this could be a fruitful path of attack here?
If there was no way to make this work with CSS, I could manually use scrollTo to reset the editor after each scroll event, but initial experiments with this result in a jagged scrolling experience (I think primarily due to your point that scroll events are only triggered after scrolling)