I’m trying to achieve a similar effect on Code Mirror that would be achieved by doing overflow: hidden on a div.
In practice this means:
no visible scroll bars
when “scroll action” takes place on the editor, the website body moves itself (i.e., impossible to scroll editor relative to the website)
P.S.
A simple “overflow: hidden” didn’t work because it looks like CodeMirror creates a separate div for vertical scroll bar and horizontal scrollbar. My guess is that javascript is used to handle actual scrolling behavior. Do I need javascript to revert this?
Thanks a lot Marijn, I’ve noticed this API command, but it looks like that’s actually equivalent to calling overflow: hidden on the verticalscrollbar div, which wouldn’t actually lock the editor - it would only hide the scrollbar.
Yeah - completely agree it’s non-conventional. Need it for a debugger. The idea is to have two modes - debugging and editing where the debugging mode locks the editor and is able to jump around and the editing mode is default Code Mirror.
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)
To try and fix 3 it seems like one would have to use the same “kludge” you used to deliver smooth scrolling to cancel it (basically like 3 just with lower latency). At this point I don’t fully understand how you were able to make scrolling so smooth through javascript. Any hints?
The scrolling (except horizontal wheel scrolling) is native. That’s why many of these hacks were necessary—just overriding it entirely is easy, but a poor experience.
But - I still don’t understand how a scrollbar in another div can move “natively” in response to scroll event in the editor div? How are you able to make it receive the same scroll events?
Is there any way to turn scrollTo into an animated/smooth scroll? I know it’s not part of the API but would this even be achievable based on what you’ve mentioned above?
CodeMirror’s scrolling isn’t implemented as a transform, so it’d be hard to animate with CSS. You can, of course, call scrollTo very often and try to get the effect that way, but it probably won’t be quite as smooth.