Mouse wheel on Windows should scroll an exact number of lines (respecting system preference) - NO version of Brackets has this yet

[thany]

My pc is set to scroll exactly 3 lines on each "click" of the scrollwheel (it's the default setting even). But Brackets manages to scroll further to about 6,5 lines in my case. This depends on the size of the editor font.

Scrolling by scrollwheel should always adhere to the system setting and should not vary by font size or line height.

(I'm also thinking if the scrolling machnism should snap to lines like almost all editors, rather than be smooth... I guess that one is personal preference)

Using Brackets 35 on Windows 7x 64.

[peterflynn]

Marking Win-only since Macs definitely don't do quantized scrolling

[peterflynn]

@thany Does your mousewheel scroll the correct/desired amount in any of these places?

• The plain textarea under "Example" here (if you paste in some long text)
• The CodeMirror demo here
• JSFiddle (if you paste in some long text)

[pthiess]

@peterflynn , I'd call it a low priority.

[thany]

Sorry for the late reply.

Yes, all three scroll too fast. I suppose it's a problem (or missing feature, or an existing feature that's not used) in webkit/blink then. It seems this is one of the consequences of using a webbrowser engine to build a normal program. These engines tend to do things differently than the underlying OS.

Still, I do think this needs fixing. Personally I'm very much used to the scrolling speed I've set up.

Btw, doesn't this go for Mac as well? I'm sure you can perfectly well attach a mouse with a "clicky scrollwheel" to a mac. Then, something has to determine how much one "click" scrolls, right? On Windows, this setting is easily found; on Mac... No idea.

[peterflynn]

Marking 'move to backlog' due to the significant effort that would be involved, and marking CodeMirror since the fix would have to be down in the CM scrolling code (unless it's fixed in webkit instead)

[marcelgerber]

I can repro that, too (Win 8.1, in browser and in Brackets itself), but Brackets (or WebKit, whatever) does not completely ignore that system setting: As you change it, the amount of scrolled lines changes, too.

Btw, both Internet Explorer and Firefox mind this setting, at least in the CodeMirror demo. Seems like this is really a WebKit problem.

[bagusflyer]

My mac touchpad scrolling is also too fast. Almost can't use. Have to use arrow key to scroll down now.

[thany]

SAPlayer, although it doesn't ignore the setting, it does implement it incorrectly. As Windows has this setting to explicitly scroll an X numer of lines, it shouldn't even be possible to scroll half a line.

It appears Brackets scrolls a certain number of pixels. IMO, a code editor should always scroll whole lines, unless using a device that allows smooth scrolling such as touch-input or a clickyless scrollwheel.

What's more, Ctrl+Arrow up/down does scroll whole lines at a time. So it must already be possible to do implement scrolling whole lines... What remains is to get from the OS how many lines.

[njx]

My understanding is that the problem is that the actual delta values we get from mousewheel events in the browser are not consistent across browsers or platforms, so it's hard for CM to know how many lines to map a particular delta value to. I haven't looked into it in detail myself to figure out if there's a simple mapping we could just hardcode per browser, though.

[thany]

Why per browser? Brackets is based on the Blink engine, right? That's just one "browser".

That only leaves Windows and Mac to take into account as the two largest target platforms. Now, I'm not sure if there's a difference between versions of these OS'es, but as far as my understanding goes, Windows at least has been (fairly) consistent.

Linux is a whole different story of course...

[njx]

The core code editor in Brackets is a separate library called CodeMirror (https://github.com/marijnh/CodeMirror), which is what actually draws the text and handles things like scrolling. That's built to work across browsers, and it's the part that would need to be fixed to address this issue.

(Also, eventually we want Brackets to work in-browser as well.)

[adammesa]

Any updates on this? I'm having this issue as well, except one click of my scroll seemingly moves my view port down 28 lines... making the code editor extremely unusable if I want to scroll with my mouse wheel... ctrl + arrows seems to be the only solution for me. :(

[marcelgerber]

The problem that got worse with Brackets 1.1 is tracked in https://github.com/adobe/brackets/issues/10214.

[peterflynn]

Clarifying title to differentiate better from the regression in #10214

[thany]

Not fixed in 1.2. Why? This is a pretty serious, and blatanly obvious problem!

Could've been dead simple to just include a previous (working) version of CEM until they fix it on their end.

[peterflynn]

@thany It's not at all simple to revert to an older CEF -- which by the way, would bring back a whole bunch of other bugs that other Brackets users might care about. So please help us nag the CEF team to get it fixed, or submit a patch over there :-) That's the best route to resolving #10214. (Note: the issue described here has never worked, so I assume you're referring to #10214 instead).

[thany]

Another workaround you could add (or could have added) is a fixed scrolling distance for each tick of the scrollwheel. Just 3 lines, or 5 lines, or 100px, or whatever. Then don't respect the setting in the control panel. At least don't make it scroll half a screen for one tick.

I'm sure there are loads of libs in loads of languages, that provide something suitable.

Either way, I don't think it's fair to release a new version and not have fixed such an obvious regression bug.

[avim]

I've that problem too and I will not update the version of brackets until this issue is fixed.

[valnub]

Same problem here. I wouldn't call this "low priority". It has a decent impact on the usability of Brackets. It's so annoying during coding that I am actually thinking about going back to Sublime :-(

[peterflynn]

@avim @valnub You are both probably looking for #10214, not this bug.

[thany]

STILL not working in the latest update. Sorry guys, but this is getting embarassing.

[50l3r]

+1 I love Brackets but your scroll its very shitty :p

[valnub]

I use Atom editor now. It's way superior compared to Brackets.

[Lucas2929]

Try going to 'device drivers' click on 'mice and other pointing devices' when you click on that, it should drop down...In the drop down box,Find the driver that corresponds to the mouse your having issues with....RIght click on it----you'll get another drop down box...In that drop down, click on properties...When that screen opens-click on the 'driver' tab at the top....in the 'driver' tab click on 'roll back driver'......That's what made my mouse working correctly again when I was having the same issues....

[thany]

Progress update please?