Mac: Throw-scrolling upward in the file sometimes jumps downward during scroll

[njx]

I haven't filed this because I can't come up with reproducible steps, but it happens to me frequently, so I thought we should record it. It's been happening for a long time, so it's not a 1.0 blocker or anything, but it is pretty annoying. (I think someone else filed a similar issue, but it was tangled up with a bunch of other stuff in a different bug, so I wanted to capture this separately.)

The symptom is that if I'm at the bottom of a file, and I throw-scroll upward (by swiping down on the trackpad), sometimes the scroll will go a little ways upward, then jump back downward. It will keep happening if I keep trying to scroll, though eventually it might "break through". Usually when it happens I'll refresh Brackets, hit Cmd-Up to get to the top of the file, or something similar, and eventually it fixes itself.

I can't figure out how to reliably reproduce it. Sometimes it seems to happen if I switch to a file whose previous scroll position was at or near the bottom. Sometimes it seems to happen if I start at the top of a file, hit Cmd-Down to get to the bottom, then start scrolling up.

I'd say it happens to me at least once a day.

[dangoor]

Did you switch branches or in some other way alter the Brackets code on disk while Brackets was running? I've seen this same behavior and it seemed to me to happen when CodeMirror or other editor code changed out from under the running Brackets (which is weird... I don't know why that would be a problem, and I also don't have reproducible steps so this may actually be unrelated).

[njx]

Nope, it happens to me all the time, and I'm not pulling master that often.

[dangoor]

Interesting. I'll keep an eye out for this sometime when I'm not frequently reloading Brackets.

[ingorichter]

@njx, do you see this on 10.10 or 10.9.x?

[njx]

I saw it regularly on 10.9 before I upgraded to 10.10

[soluml]

I'm seeing this as well. I haven't been able to pin-point exactly when it happens. Seems like it has something to do with version controlled projects though, likes to happen after a commit.

[willsteinmetz]

@ingorichter It's happened on 10.9 and 10.10 for me. I've noticed what @dangoor mentioned about it happening a lot when switching branches and tend to quit Brackets when swapping so I don't have to deal with it or refresh every time I swap (which admittedly is probably easier but Brackets loads very fast for me so it's about the same speed either way). It's also happened for me with what @njx mentioned when switching between files. I can't always reproduce it but it seems to happen for me more when I have a lot of files open as opposed to only a few files.

[willsteinmetz]

Right after that last post, I noticed it also happens when there is an overlay of some sorts. I use the Git Brackets extension which will put up overlays for various tasks and the jumping seems to happen with that. I'd venture to say it's not the Git Brackets extension because it will also happen with the extension manager overlay as well. Hopefully that can help narrow down part of it.

[lrebrown]

As I mentioned in the referenced issue #10293, I am also experiencing this issue.

I'm using brackets v1.1 on Windows with git 1.9.5. My only extension is 'brackets git'. I also do not have a reliable way to reproduce the issue, but as queried by @dangoor, yes, I am doing a lot of rebasing externally to brackets, so the files are indeed changing from under brackets.

Someone needs to remove the 'mac only' tag.

[peterflynn]

Is anyone seeing this issue able to reproduce it without the Brackets-Git extension installed? (Try Debug > Reload Without Extensions or temporarily disable that one extension).

[willsteinmetz]

@peterflynn Yes, I see this without Brackets got installed. I've always seen it.

[willsteinmetz]

By always seen it, I mean even long before I started using Brackets got which is only in the last couple of months. I've seen this problem as long as I've used Brackets (since about late 2013).

[mikedaly]

I am also experiencing this issue. I do not have Brackets-Git installed, but I do frequently change the branch underneath Brackets. I strongly suspect that it has something to do with checking-out a new branch while affected files are opened in Brackets, though I can't be sure.

[peterflynn]

@mikedaly If a file changes while you're in the middle of a throw scroll in that exact file, I'm pretty sure that will disrupt the animation. That's probably prohibitively expensive to fix... but it also seems pretty rare. What we don't want is 'false' positives where other files changing would disrupt scrolling, because that could happen a lot more often.

[mikedaly]

@peterflynn It definitely isn't happening simultaneously. Typically I have a set of git repo files open in Brackets, then switch the branch using SourceTree or git command-line, then switch back to Brackets after the checkout is complete. If I then start a scroll/throw, it is as this point that I see the 'jumping' behavior.

[sweatherall]

I have had this issue very often as well, very similar to how @mikedaly described his experience, except I do not use SourceTree.
I always just quit brackets and re-open it to fix the problem, however it is becoming quite the inconvenience when I am in a workflow.
I am using Mac + release 1.2.

[mikedaly]

I am also on Mac and have been having this problem since before the 1.0 release. It remains today with 1.2. I wonder if it is Mac-specific.

Anyone NOT on a Mac experiencing this problem?

[njx]

It feels to me like I've been seeing it a lot more often recently as well. I've been trying to figure out steps, but haven't been able to reproduce it on purpose.

I have a suspicion that it's related to switching back to a file (possibly using Quick Open) that was scrolled to the bottom the last time you looked at it, possibly combined with the file having been reloaded in between because of external changes (e.g. switching branches in git). When I have a little time I'll see if I can find a good repro case.

[njx]

(To @peterflynn's point, it isn't related to the file changing during a throw scroll...for me, it happens when switching back to a file well after it's been reloaded.)

[njx]

One other thing I've noticed: if I get into this state and I do Cmd-Up to jump to the top of the file, then scroll down, it generally fixes the problem, but I notice that as I'm scrolling down, the bottom fourth or so of the screen is blank during the scroll. So it seems like CodeMirror is getting into some state where its idea of the size of the visible region is wrong.

[sweatherall]

@njx it also happens to me on switching back to a file well after reload (opposed to during a throw scroll).

[njx]

Okay, I think I have a set of reasonably reproducible steps (though not a handy set of test files).

1. Open a git repo
2. Take some file in the repo and edit it in a branch so its size changes significantly (many more or fewer lines)
3. Scroll to the end of the file and set the cursor near the end
4. Switch to some other file
5. In the repo, switch back to master
6. In Brackets, switch back to the file from step 2
7. Throw-scroll upwards

If the bug doesn't show up, scroll back to the bottom of the file, then do steps 4-7 again, but switch to the branch instead of master in step 5. (I think the problem is most likely to occur when the file shrinks while it's not the current document.)

I have a possible fix in #11043 - I've been running with it in Brackets today and I haven't seen the throw scroll problem, whereas if I switch back to Brackets master I can get the bug to occur pretty much immediately. However, since I'm not 100% sure of the repro steps it's still possible that the bug might occur even with the fix - I'll continue running with it over the next few days to see if it shows up again.

[njx]

#11043 has been working well for me. If anyone else on this thread is running off master, please give it a shot and see if it fixes the problem for you.

[zaggino]

#11043 has been merged to master -> I've tested it and it seems to fix the issue. If anyone else can test the latest master for this, it'd be great :)

[njx]

@zaggino: @peterflynn pointed out that with my fix we might now be refreshing more often on document switches. I haven't actually gone through and figured out the exact sequence to see if that's happening - the concern would be that it adds lag to switching documents if we refresh twice.

My off-the-cuff suspicion is that the problem was that we were refreshing when the editor became visible (in notifyVisibilityChange()), but that that was too late because the scroll position gets reset in _resetText(). If that's the case, then we might either need to actually refresh twice, or we would need to figure out how to suppress one or the other.

[zaggino]

refresh gets now triggered 3-times when switching documents:
src/editor/Editor.js:935:26 - your change in Editor.prototype._resetText
src/editor/Editor.js:1946:26 - also in Editor.prototype.refresh
src/extensions/default/CodeFolding/main.js:227:16 - from createGutter method which is executed every time document changes