A nuisance scroll error from core


Sometimes when I tell the editorView to scroll the log shows EditorScrollView scrolled when it shouldn't have. This comes from atom.0.120.0\tools\atom\resources\app\src\editor-component.js:1155.

It doesn’t do any harm but it is a bug since I’m using a legitimate method of EditorView. Also I hate the log being cluttered up with garbage. It makes the log harder to read when debugging.

windows 8.0 with atom 120


Have you opened an issue on the repo?

When you say it does this “sometimes”, is there any pattern you can make out as to what exactly seems to trigger this error?


It’s triggered when a ScrollView node emits a scroll event, which apparently it shouldn’t; the event listener registration:

The actual event handler:

Looking at the code, this is not a bug. This is something that is being specifically handled, most likely to root out and prevent this from happening.

Also, follow @batjko suggestion and open an issue for this, as well as trying to figure out what you’re doing that triggers it.


Hmm, is it a package that’s doing it then? Can you catch it on the stack?


It’s being caused by code in a package he is developing, most likely indirectly via some function related to scrolling. A bit of code (to reproduce the issue) would be extremely useful.


This is my only code related to scrolling. I don’t see anything wrong. I’d try to isolate the problem but that would be quite hard.

    setViewPos = (pos, view) ->
      if pos and view
        [topLine, cursPos] = pos
        view.scrollToBufferPosition [topLine+2, 0]
        view.getEditor().setCursorBufferPosition cursPos
# called by
          setViewPos pos, atom.workspaceView.getActiveView()


@buffer.setText @curText
@editorView.scrollToBufferPosition [lineNum+2, 0]
lineOfs = @buffer.characterIndexForPosition [lineNum, 0]
cursPos = @buffer.positionForCharacterIndex lineOfs + charOfs
@editor.setCursorBufferPosition cursPos
@statusView?.setMsg @getState()


I didn’t think of that. I’ll give it a try.


Also, does it still happen if you comment out the .focus() line?

I don’t remember having to call a .focus() too often after that kind of thing, although I do more of that in my spec test, but I assume it’s similar behavior there (or at least should be).


I had to do that to get the cursor displayed back up in the text I just loaded. It’s not like find/replace where there is any focus needed in my control bar.


ah, my code does


and then


Does it make sense to call the .focus() after or before in your case? Maybe effectively the same not sure. Try activate()? Not sure, that might be doing a whole lot more or less than you need. Worth a shot?


I’ll try everything. Thanks.