Editor & file tree scroll too fast when using mouse wheel (starting in 1.1)

[thany]

Update: This bug will not occur in Brackets 1.3, as it has a built-in workaround. The bug remains open to track getting a "real" fix in CEF, and removing our workaround.

---

The editor & file tree scroll too far for one "tick" of the scroll wheel. I've set it in my mouse properties to "3 lines". The editor and the file tree scroll about 22 lines, which is just too much and nowhere near what I've told my system to do.

The scroll distance should be similar to what is set in the mouse properties, no matter what sort of thing is being scrolled.

This is in Brackets 1.1 on Windows 7. Also happens without any extensions.
This problem did not occur in Brackets 1.0.

For reference, these are the properties I'm referring to:

(Ooh, and the installer doesn't let me install 1.0 anymore... that's nasty)

(edited because the code editor has the same problem, I just noticed)

[thany]

Managed to downgrade to Brackets 1.0. Issue does not occur.

Let's call this a regression. The issue used to exist in a much earlier version of Brackets, but magically got solved or worked around at some point. And now it's back.

[JeffryBooher]

@thany I've confirmed that the scroll wheel does throw farther than the previous version. 1.0 scrolled about 7 lines in the editor and 1.1 scrolls about 11 lines. I'm not sure why you're seeing different results than I but this indeed is a problem. Does 1.0 only scroll 3 lines for you?

[gmaggio]

My case is much worse in that it jumps 32 lines! It's unbearable to work!

[zivoradmilekic]

I have same issue. Scrolls 10 lines. It is hard to work!

[marcelgerber]

Yeah, me too, it scrolls 24 lines over here while it's set to 6 lines.

[thany]

@JeffryBooher Not three lines, but more in the neighbourhood of 5.5 lines. Close enough. Much closer than the current 21 lines anyway.

[Max-Enrik]

70 lines. How can I fix it? Please incredible annoying. Please help me!

[peterflynn]

Hmm, sounds similar to this Chrome bug: https://code.google.com/p/chromium/issues/detail?id=349921, but it's clearly worse in Brackets than in Chrome: e.g. on http://codemirror.net/mode/javascript/ it scrolls 8 lines per "click" of the scroll wheel, while in Brackets with the same font setting it scrolls ~12.5 lines instead (vs. Brackets with the 1.0 shell, which scrolls ~6.5 lines).

This older bug says Chromium always scrolls exactly 100px, regardless of font size or OS scroll-wheel setting -- and that seems to still be how Chrome behaves on my machine. But in Brackets, it now scrolls 200 px per mouse wheel click instead.

Getting it to exactly match the OS setting seems close to impossible given that Chrome doesn't support it, so getting back to the standard Chrome behavior, i.e the Brackets 1.0 behavior (1/2 the scroll speed of 1.1) should be the goal here.

[peterflynn]

I can repro in cefclient, so I'll file a CEF bug for this.

[peterflynn]

CEF bug: https://code.google.com/p/chromiumembedded/issues/detail?id=1481

[equinox]

Any potential way around this yet? (I'm also on Windows 7 and noticed it only since upgrading to 1.1).

[geoken]

I was having this issue too. Scrolling about 12 lines per mousewheel click (system was set to 3 lines per click),

I used a freeware app katMouse ( http://ehiti.de/katmouse/ ) which allows you to set per app scroll settings that override the system wide ones. Setting it to scroll one line per click for Brackets translated to roughly 4 lines per mousewheel click in. That's close enough to my system wide default of 3 lines per click to be live-able.

[gmaggio]

@geoken : This actually gave me an idea to fixing this issue.. for my specific case, at least. I had also used KatMouse (v.1.04) and set it up to override the scrolling function for Brackets. On the contrary to you, however, removing this setup actually fixes the problem.

[thany]

I wonder why the amount of lines-per-tick is different for everyone. Is it not scrolling x lines, but instead scrolling x pixels or something?...

[gmaggio]

Just to continue my report regarding the use of KatMouse... strangely enough, though, if I disabled the app, the problem returns. Meaning I have to leave it running for the problem to be fixed.

[thany]

I just installed KatMouse icw Brackets 1.0, and set it to "2 lines".

Wow :)
It now scrolls even more closely to my mouse setting of "3 lines". It's scrolling 4 lines per tick.

But if I upgrade to Brackets 1.1 (really, it's a downgrade right now, as far as I'm concerned), I want to set it to something like "0.3 lines", which isn't possible, but it would be the right setting if it were possible. Even setting it to "1 line" is far too much for Brackets 1.1, causing it to scroll 8-10 lines per tick.

[peterflynn]

@thany Exactly -- see my comment above, in particular the link to Chromium bug 38378. Brackets scrolls a fixed number of pixels, it has always done that, and that's not easy to change since the behavior is baked deep into Chromium. The bug here is that the fixed number of pixels is suddenly twice as much as it used to be. That is a CEF bug, which I've linked to above also.

[peterflynn]

Btw, everyone who's affected by this bug -- please go to the CEF bug linked above and click the star. CEF bugs are prioritized based on number of affected users, which is decided by how many people have "starred" the bug...

[ValentinJesse]

Horrible experience with Brackets. Keep installing it since build 19 and i always go back to Sublime Text because of different reasons.

22 lines scrolled at once ? Really ? How is this even a problem in 2015 ? Also, that delay when switching between panels in split view. Uhgg!

I will keep installing it, though. Maybe one day...

[equinox]

Yeah, it is rather annoying. I'm currently using an extension that makes the scroll a lot smoother but it obviously still scrolls far too far - 17.5 for me, currently.

I actually had an extension installed that scrolled from where you were to the bottom of the document - and then when scrolling up it went all the way to the top...... I almost gave up on Brackets because of that, thankfully, it was another extension; not Brackets.

[peterflynn]

@ValentinJesse & @Equinoxdawg, please star this bug to raise its priority: https://code.google.com/p/chromiumembedded/issues/detail?id=1481. The fix has to come from there, not from Brackets.

@ValentinJesse Can you file a new bug on the delay you're seeing when switching split view panes? There shouldn't be any delay. How long a pause are you seeing?

[aniforprez]

Atom is now my code editor of choice and I absolutely recommend it. Lots of development happening and almost all functionality from Sublime is in there now with plugins. Brackets I opened, used a couple of days, found it unusable after I encountered the scroll issue and now the only reason I think about it is when I get notifications for comments on this page.

[alphatwit]

I don't like the tabs of working files in either sublime text or atom. My list gets pretty long and a horizontal scroll is too much of a bother. I'm trying Visual Studio Code now. It has the same layout as Brackets with the working files above the file tree

[aniforprez]

@alphatwit I think tree-view-open-files does that for you in Atom. You can disable the tabs package and use this instead.

[alphatwit]

@aniforprez thanks for the tip, its exactly what I need

[alphatwit]

Still here, still hoping someone will recognize how ridiculous this issue is.

Edit: I noticed a weird thing, because it wasn't scrolling like this yesterday. I don't close Brackets between work days while my laptop hibernates. So I just restarted it, and for about 10 seconds it was taking me 4 clicks to get through my working files list instead of the 2 that are in the image above... But then it went back to 2 again. I restarted it again, and it's giving me 4 clicks now reliably.

This is leading me to believe that there is actually some kind of bug, instead of it just being a weird Windows behavior.

[thany]

It is indeed a bug. One that has two parts to it:

• It doesn't respect the scroll speed setting from the control panel
• It fires the scroll event twice for each mouse wheel tick

Both bugs exist because of a dependency on CEF, an external component that the Brackets team have almost no control over. So since other editors do not suffer from these problems, perhaps CEF was a horrible choice.

[alphatwit]

https://bitbucket.org/chromiumembedded/cef/issues/1481/windows-2171-window-scrolls-too-much-with

It looks like they're claiming that it's resolved on their end.

[thany]

Is this issue resolved for 1.6?
It would be about freaking time, after more than a year.

[abose]

Tagging @swmitra

[alphatwit]

It is not fixed - Release 1.6 build 1.6.0-16680

[thany]

Come on guys.

I understand the devs couldn't give a flying monkey's toss about Windows, but even then, how can you release version after version with a straight face with such a blatantly obvious bug still in there?!

Fixing this bug is WELL overdue by now.

[thany]

Almost two months later... Any progress?

A bug since 1.1, affecting ALL windows users by some degree. And you're happily adding features that break unrelated other features.

Please realize that this bug has existed for 15 MONTHS. Just putting that out there.

[aniforprez]

Thank you @thany for following up with this issue and with the continuous encouragement but at this point it seems clear that this very core issue is in the backburner and might never get resolved. Personally, I'm unsubscribing from this discussion and abandoning brackets as an option. I'm done waiting for this to be fixed.

[thany]

The point is that this is (or should be) a fairly simple fix. So I want to understand why this isn't being addressed.

If someone from the team at least could give some sort of explanation why they're so unwilling to resolve this.

But let me make one thing clear: the fact that everyone has either accepted the problem, or has found a workaround, is no excuse for not solving anything.

[geoken]

@thany

I think most people's workaround is just use Atom or VSCode and ditch Brackets.

The general feeling is that Brackets has just been a beta test for adobe to work out kinks in their next gen dreamweaver and they don't really care about it's viability as a standalone open source project going forward.

[niiapa]

Just started using Brackets. Kill me now. This problem is so annoying... How can this issue be there for years?! I thought I was one of the few who had it buggy but damn!

[alphatwit]

welcome to the club :)

[solid-pixel]

Apart from @marcelgerber 's fix another way around that is to install this smooth scroll extension. This would make your mousewheel scroll 1 line at a time (approximately, since my brackets doesnt scroll exactly line by line but it's more like one line and a half at a time, with or without that extension)

http://brackets.dnbard.com/extension/brackets-smooth-scroll

Though this is a shame and I think I'm gonna move to Atom very soon as Brackets is giving me more problems than solutions.

[50l3r]

I just came from atom and not if I recommend it to you :s Too much bugs.

Scroll increase the velocity progressively. Simply add option to remove this.

[thany]

@Tukano Moving to Atom doesn't solve the problem. And I'm a habits-person, so moving to another editor is hard on me :)

At any rate, Brackets should have had a workaround like that for at least a year, but not even that, let a alone a proper solution. Unbelievable. It's like the devs could give a monkey's toss about every Windows user.

@50l3r Accelerating scroll is an OSX-quirk, afaik. It's greatly annoying, so I'm happy not to use OSX ;)

[nethip]

Apologies for being late in jumping onto this thread. We are going to upgrade CEF for 1.7. All of the changes are happening in this branch. https://github.com/adobe/brackets-shell/tree/prashant/cef-upgrade-latest.

We are 2-3 weeks away from the release. https://github.com/adobe/brackets-shell/tree/prashant/cef-upgrade-latest branch is buildable. So essentially one could build appshell from this branch and start using Brackets. Please refer to this wiki https://github.com/adobe/brackets-shell/wiki/Building-brackets-shell.

Note: we might have to revert @marcelgerber changes once we upgrade CEF to latest.

[thany]

@nethip CEF 1.7 doesn't tell me a whole lot, but since you mention it in this thread, can we assume it finally fixes the problem?

Also, this time, please do arrange a full front-to-back regression test. We don't need another Ctrl+Z problem on top of the one that's already still there. An upgrade of the framework may well cause issues that it shouldn't relate to (which is an antipattern, so it shouldn't happen, but it has happened)

[marcelgerber]

This issue has finally been resolved as we updated our shell to a newer version of CEF (our embedded WebKit renderer).
Closing. (What a relief!)

(The new shell will ship with Brackets 1.7, so you still have to wait some)

[thany]

That's what we got around the time 1.3 got released, but then the fix turned out to make matters even worse (it wasn't consistent anymore). I do hope this fixes it.

Also I hope the new shell doesn't introduce all kinds of other problems (like the previous shell update), so please please test it well. And not just on whatever OS you're using. Please.

Btw, what's the fix?
Will it respect the number of lines to scroll, as set in the control panel?

[marcelgerber]

CEF used to act on a scroll event twice. This has been fixed now.
That is, Brackets will now behave like Chrome does - it will scroll a fixed amount of pixels, not a number of lines.

[thany]

@marcelgerber so that's still wrong. It doesn't respect the OS setting, and not only in Windows if it's a hardcoded pixel amount.

Brackets may be built on top of a WebKit engine, but it's not a website. Scrolling a configured number of lines is perfectly doable, because the height of one line is known.