Gutter lags behind scrolling in Firefox nightly

[staktrace]

In Firefox nightly we have enabled asynchronous panning, which means the visual scroll position can run ahead of what you can see in the DOM and via the 'scroll' event. This is causing an issue in CodeMirror installations where the gutter (whose position is updated on the scroll event) lags behind the rest of the scrollable area when scrolling horizontally. You can see this in action by going to a page like https://codemirror.net/demo/buffers.html in Firefox nightly and scrolling horizontally with wheel or trackpad (unless you have a horizontal mousewheel this is easiest to see using the Mac trackpad).

We have https://bugzilla.mozilla.org/show_bug.cgi?id=1160601 on file in bugzilla for this issue, and I have posted an attachment to that bug that demonstrates how the same design might be implemented using position:sticky instead, which doesn't have this problem as we can reposition it asynchronously in the compositor. I was hoping I could get some guidance as to what it would take to integrate that change into CodeMirror. I tried briefly to make a CodeMirror patch but it seemed rather involved and so I figured I should ask before spending more time on it. (Also I'm not really a JS hacker so it's a lot more work for me than it would be for one of you).

Note also that the asynchronous panning behavior will probably start shipping to users in Firefox 45 or (more likely) 46.

[marijnh]

That's interesting, and I didn't know about position: sticky, which would indeed be a great fit for this.

A bigger problem is viewport updating. I suspect that if you scroll quickly with async panning enabled, you'll be able to see empty space coming into view because CodeMirror doesn't know where you're scrolling to. A similar issue exists on mobile platforms. I am not aware of a solution (if you know of some API that would help the editor predict what is going to be scrolled into view, or are in a position to promote the introduction of such an API, let me know)

[theres-waldo]

if you know of some API that would help the editor predict what is going to be scrolled into view, or are in a position to promote the introduction of such an API, let me know

Coincidentally, we were just talking about introducing such an API last week. https://bugzilla.mozilla.org/show_bug.cgi?id=1232491 is tracking this work.

[marijnh]

I took a look at this. But individual line numbers are rendered inside the line's element, so they can't be direct children of the scrollable element. Sticky positioning (or at least Gecko's implementation) seems to only work when the positioned element is a direct child of the scrolling container. That isn't the case here (in fact, there are several positioned parents between the line number and the scrolling element).

So this doesn't seem to be something that's easily fixed with sticky positioning. It'd require a serious overhaul of the way the gutter is rendered, which has its own problems (the line numbers are there because reliably aligning them vertically is a huge pain otherwise).

[staktrace]

Note that the way the gutter is rendered causes pretty poor performance because Gecko ends up creating separate layers for each line number. It has no way to know that they will always move in sync and so it can't coalesce them on to the same layer, which would be much better. See https://bugzilla.mozilla.org/show_bug.cgi?id=1239615#c11 and nearby comments.

[marijnh]

Since the gutter elements vertical position needs to be tied to the line they belong to, putting them into a single layer isn't really something that I know how to express in CSS.

[staktrace]

Yeah that's fair. There's no reliable way to do it from CSS because it's up to the browser implementation, which can change over time. Even my prototype with position:sticky suffers from the same problem, although I think that in that case we can modify Gecko a little to combine them into a single layer.

[Petergatsby]

Have there been any updates to this issue? I'm experiencing this in Chrome.

[leeoniya]

ran into this today when scrolling horizontally on a pretty fast mobile phone in Opera and Chrome (both Blink, i think):

http://leeoniya.github.io/domvm/demos/playground/#infinite-scroll

i'm gonna try position:fixed/left:0 and/or css transforms

with css transforms it may be worth adjusting an inserted styleaheet rule rather than poking style on each gutter element.

also https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener#Improving_scrolling_performance_with_passive_listeners

[leeoniya]

using translateX() instead of left definitely helps.

[adrianheine]

We are working on a rewrite (CodeMirror 6) that uses position: sticky for the gutter, and we are currently raising money for this work: See the announcement for more information about the rewrite and a demo.

Note that CodeMirror 6 is by no means stable or usable in production, yet. It is highly unlikely that we pick up this issue for CodeMirror 5, though.

[leeoniya]

already noticed :) and pitched in €100.

https://news.ycombinator.com/item?id=17859663

[staktrace]

@adrianheine consider applying for a MOSS grant. The Firefox devtools use codemirror too so that should qualify under the foundational technology section.

[marijnh]

We received a grant from the MOSS project a few years back—but maybe that doesn't mean we're disqualified for another. I'll bring it up.