Brackets: 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]

I'm scrolling 27 lines at a time. It's VERY annoying. I'm using Brackets 1.2.Pre-Release.

[peterflynn]

@aniforprez See my comment above -- please star the "chromiumembedded" bug. Our hands are tied until that is fixed.

[jonathan-stone]

Here's a workaround that worked for me on Windows 7:

1. Install X-Mouse Button Control (http://www.highrez.co.uk/downloads/XMouseButtonControl.htm)
2. With Brackets running, click Add and choose Brackets.
3. Make sure Brackets is selected in the list, and go to the Scrolling & Navigation tab.
4. Under Advanced Window Scrolling, change the Scroll Method setting to "Method 1 (SCROLL Msg)"
5. Click the Apply button.

[mmoore99]

@skypecakes Your workaround works perfectly for me on Win 8.1.

I had tried the KatMouse suggestion from above and it worked for Brackets, but introduced some compatibility problems with some other apps.

Thanks!

[thany]

@skypecakes Good suggestion, but it doesn't work for everyone. For example, me :)
X-Mouse does two things:

• It ends up messing up scrolling for other applications, even when only Brackets is whitelisted. Slightly, but still.
• The scrolling problem in Brackets is so severe (for some, including me), that even setting X-Mouse to the lowest possible setting, it still causes Brackets to scroll way too far for each tick.

[MarcelGerber]

I filed https://github.com/codemirror/CodeMirror/issues/3109 as a maybe-meantime-fix we could use if it gets implemented.

[jonathan-stone]

@thany , maybe this is irrelevant for you since X-Mouse messes up scrolling for you in other applications, so you might not ever want to use it; but maybe it will help someone else.

There are five different scroll methods to choose from in the Scroll Method setting of X-Mouse.

I only tried the first one and it worked, so I stopped experimenting.
Did you try any of the other methods? I wonder if one of them might do the trick for you.

[mmoore99]

@skypecakes, I spoke too soon. It turns out that X-mouse doesn't work correctly when accessing vmware virtual machines.

[andfaulkner]

I'm having the same issue, but I was also able to work around it using KatMouse.

@mmoore99 Are you using application-specific settings in KatMouse? I had the same issue until I defined the custom setting solely for Brackets:

R-click KatMouse systray icon --> Settings --> Applications tab --> Add --> select Brackets executable in dialog --> click new Brackets.exe list item --> [set custom scroll here]

[Xety]

@skypecakes Thanks, your method worked for me !
I hope this issue will be fixed as soon as possible, because we can't work with a 24 lines scrolling...

[peterflynn]

Brackets release 1.3 will have a built-in workaround for this issue, so the mouse hacks should no longer be needed to restore the Brackets 1.0 scrolling behavior.

Lowering priority and leaving open, since we do eventually want to pick up a CEF fix and remove the hacky workaround.

Note: this does _not_ make Brackets 1.3 respect the OS setting for number of lines to scroll. No version of Brackets has ever done that (nor has any version of Chrome) -- please file a new, separate issue for that feature upgrade if desired.

[hmemcpy]

Sorry to bump this, I just installed the 1.3 pre-release build (1.3 build 1.3.0-15996 (release 2fbd9d392)) - I still experience the scrolling issue.
Is there anything I should enable for the workaround to... erm.. work? :)

[MarcelGerber]

I think my fix didn't yet make it into the prerelease, but it will be part of the release that'll be available in a few days.

[hmemcpy]

@MarcelGerber

Just wanted to let you know that for the most part, the fix is great! However, sometimes (and I couldn't really find out when), the scrolling misbehaves again - becoming too fast. If I reload Brackets (Shift-F5), the scrolling goes back to normal (fixed) state.

Will try to repro... (using 1.3 build 1.3.0-16022)

[thany]

Yep, whether it's a real fix or a workaround, I don't really care that much. It seems to be working okay for now. The scrolling speed _should_ really respect the control panel setting, but since (I imagine) many users never touch this setting, the current scrolling speed would be okay-ish for most Windows users.

Thanks so far :)

@hmemcpy I haven't run into your issue yet. Maybe a plugin is causing it?...

[aniforprez]

This fix seems to have solved the issue for the most part for me. At least now I'm scrolling at a reasonable 6 lines instead of the ridiculously unusable 27 previously. Thanks!

[thany]

Unless this happens :)

[ray1618]

Still have te problem, using windows 10 and brackets sprint 4 build 1.4.0-16380.
Seems the longer the file the more lines i get scrolled, some files up to 20 lines per tick

[ValentinJesse]

You are not the only one. I've posted in here on January about the scrolling problem and the lag that happens when switching between windows in vertical split.

Still using sublime text...

[mounitsyna]

Same here. Windows 10, Brackets 1.4.0-16380

[Phiphel]

Still an issue as of 1.5.0-16538

[thany]

Yep, still an issue in 1.5.0.

I don't to be rude, but leaving such a flagrant issue open for so long is not good. Every Windows user will have this issue, some are annoyed by it more than others though.

[thany]

Ctrl+up/down scrolls the editor by exactly one line. So brackets does know how to scroll one line. Then, how hard can it be to scroll three lines??

[mounitsyna]

Seems to be (not entirely) fixed for me in 1.5.0-16538

The working files list still scrolls unbearably

[geoken]

It's definitely not fixed in 1.5.

i'm using it on Win 10 and currently getting close to 20 lines of scrolling per mouse click. What I noticed is that the lines it scrolls increases as the length of the file increases. This is actually the worst part about it for me, I could begrudgingly get used to the 6 lines of scrolling but the fact that it's variable makes that impossible. As i switch from tab to tab within my project, the results of a mousewheel scroll are basically a roll of the dice in terms of where on the page the content has jumped to.

[mounitsyna]

You're absolutely right about the length of the file (or working file list) being a factor.

Setting the mouse scroll wheel to 1 line per scroll wheel click makes it tolerable to work with long files/projects. I'm getting about 2 lines in the main work area and about 5 in the sidebar working files/directory (assuming a reasonably large amount of lines in both). If nothing else, the place I'm on doesn't just fly out of sight anymore.

[thany]

My god, this problem is still not resolved? After a freaking year?!

Brackets team, please set your priorities straight. Some people will happily move to Atom.

[mounitsyna]

seems like development has crawled to a halt since the summer.

...Atom looks nice

[ValentinJesse]

There's nothing that could replace the responsiveness of Sublime Text. Brackets is a failure. I had high hopes for it, given that i have installed it since 0.20. No more Brackets for me, that's for sure.

[thany]

This is what I mean.

[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.

[mounitsyna]

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.

[mounitsyna]

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

[mounitsyna]

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.

[mounitsyna]

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

[mounitsyna]

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!

[mounitsyna]

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.