Brackets: Scrolling sometimes reverts to being too fast

Created on 11 May 2015 · 39Comments · Source: adobe/brackets

The scrolling-too-fast-bug seems to have been resolved... To a certain point. I can't put my finger on it, but at some point it reverts to scrolling too fast again. It almost looks like there's some kind of built-in scrolling acceleration going on (like how OSX very annoyingly has, but to a lesser degree).

But right now, as I write this, the file tree is scrolling 18 lines per tick. That is still waaay too fast. The main editor scrolls 22-ish lines per tick. Also waaaaay too fast. If I restart Brackets... (doing it now)... It's back to normal again.

Windows 7 x64, Brackets 1.3. No mouse software installed, default drivers and all that. No scrolling modifiers like KatMouse, nothing like that.

Source

thany

Most helpful comment

Please find the following PRs which are going to take care of this issue.

Brackets: https://github.com/adobe/brackets/pull/12415
Brackets-shell: https://github.com/adobe/brackets-shell/pull/544

In order to fix this bug, we need to upgrade to later versions of CEF, which is a huge task by itself. If we don't see any issues around upgrading, this fix should make it to 1.7

nethip on 11 May 2016

👍2 ❤1

All 39 comments

Update: yeah it literally happens out of the blue. I don't need to do anything in order the scrolling speed to mess up again. It can happen literally anytime. It's like a ticking timebomb without display.

I'm very curious to know why this is happening. My programming skills from way back tell me that this shouldn't be too hard, but then again, brackets depends on a fairly great number of 3rd party components, which might explain how this is so difficult to tackle...

thany on 11 May 2015

Update 2: the scrolling may speed up even moments after reloading Brackets, and literally only just scrolling. So I reload, scroll some, and boom.

I'll have to revert to 1.0 for the moment. I can't work like this.

Please bear in mind, Brackets 1.2 behaviour was better actually. That one was way too fast, but at least consistenly so, and therefor workaroundable with KatMouse. This is why I can't use 1.3 for the moment. But then, older versions cause other problems. See why I'm annoyed?

thany on 12 May 2015

You can see what we did to fix this bug here: https://github.com/adobe/brackets/pull/10930
It's a hack, I know, but it at least works.

What extensions do you have installed? Maybe one of them calls body.removeEventListener?
(If you give me a list of the extensions you have installed, I could look that up)

MarcelGerber on 12 May 2015

For the moment, I've got these installed:

brackets-morecsscodehints
brackets-oncopy
brackets-various-improvements
camden.jshint
de.richter.brackets.jsonlint
gruehle.markdown-preview
html-block-selector
io.brackets.svg-code-hints
ivogabe.icons
jeffbooher.bookmarks
laron.liquid
mikaeljorhult.brackets-todo
pflynn.charcount
pflynn.svg.preview
soft-dark
talmand.disable-autoclose-tags
torin.duplicate

thany on 13 May 2015

If it happens again, could you follow these steps:

Open the developer tools (Debug > Show Developer Tools or F12)
Make sure you're in the Elements view (first tab)
Click the <body> tag
On the right, switch over to the Event Listeners tab
Expand the wheel section (if there is one), which should look like this:

Does it look like this or not? Are there any other handlers listed under wheel?
It would be very helpful to see whether it's just the handler being removed or the handler code failing.

MarcelGerber on 13 May 2015

After the scrolling speed has increased again, the handler is exactly as in your screenshot. Down to the line number even. It's also the only handler for wheel.

In the mean time, I've also figured out how to cause this issue, and how to make it go away: simply scroll a LOT. I mean vigorously. I have a Logitech M500 mouse with "tickless scrolling mode", where the scrollwheel becomes a flywheel. That definately triggers and un-triggers the issue. It's not neccesary to cause the issue - I just use it to repro it with absolute certainty. Scrolling more slowly will still trigger the problem, but less reliably.

I can cause the same triggering and un-triggering without any extensions loaded.

thany on 13 May 2015

Another update.

I've put a console.log at the point where a scroll event should get canceled. As long as the scroll speed is broken, every other scroll event _does_ get canceled properly. The different between "good" and "bad" scrolling speed is, repsectively, the wheelDelta being either +/-120 or +/-480.

That tells me there's something else, hidden more deeply within CEF (or something else) that increases the scrolling speed. It may also explain why some people reported much higher scrolling speeds than I did in my original issue about it.

Is there a way to force wheelDelta to +/- 120 all the time? Not sure if that would fix it, but for me at least, that seems like the correct delta for one tick.

thany on 13 May 2015

It would probably be quite easy to convert my PR #10685 to an extension you could utilize. It got some criticism on that it may make scrolling performance worse, though, and it only applies to the editor, not to dialogs, sidebars, panels and so on.

MarcelGerber on 13 May 2015

Not so sure about that last bit. This problem (and your solution) affects the file tree as well... After all, the handler is on the body, so shouldn't that affect the whole app?

thany on 14 May 2015

Yeah, my solution for the overall problem (scroll events being fired twice) affects the whole app.
But one solution to the problem you now face, converting PR #10685 to an extension, would only apply to the editor.

MarcelGerber on 14 May 2015

Here's my extension that works around this thing.
https://github.com/thany/brackets-scrollfix

I had to replace your code to "ignore every other event" because the two were conflicting, and there's no way to remove an event listener that I can't access the handler for. That's why I'm basically also ignoring the new preference that controls it. I know it's evil, but so is this bug.

Now I can finally get back to work :)

thany on 18 May 2015

As long as it works ... ;)

Notice though that this fix will go away at some point, and remember to then also uninstall your extension so you don't get a wonky scroll experience.

MarcelGerber on 19 May 2015

(I'm going to leave this issue open as it's still an issue that can probably be fixed by a CEF upgrade, even though you're possibly the only one who hits it)

MarcelGerber on 19 May 2015

Sigh... I am having this issue. I got here after jumping through 3 other bugs...
This is the first editor I had this ... rather bizarre, problem!
It scrolls fine for 3 lines, but then it starts scrolling 12 lines at a time!

drozzy on 25 Aug 2015

Same, except now I'm getting 20 line jumps (win10). "Shift + f5" is the only thing that keeps it from scroll-hopping :c

doppl3r on 26 Aug 2015

Here are some details I've gathered

Here are the results from my scrolling:

Sometimes ~7 lines with a scroll (A)
Sometimes ~20 lines with a scroll (B)

How to reproduce:

Open Brackets with a long document
Scroll down and observe. You will get either (A) or (B)
Spam scrolling up and down.
For a chance, you will be switched to the other (A) -> (B) or (B) -> (A)

Also, the chrome development tool is also scrolling way too fast.

danvim on 30 Aug 2015

Unfortunately, we can't do anything about the Chrome DevTools.
PR #11638 should fix the overall problem, though.

MarcelGerber on 30 Aug 2015

As far as I know, that PR should fix not just the editor, but the entire application. Same as my own (much cruder) workaround.

thany on 31 Aug 2015

Yes, it fixes Brackets as a whole (this includes: editor, Extension Manager, file tree, ...), but as the Dev Tools are completely controlled by Chrome, we can't inject any extra JavaScript in there.

MarcelGerber on 31 Aug 2015

This seems to have been fixed in CEF upstream. https://bitbucket.org/chromiumembedded/cef/commits/7d01f373fbc8465e6d68def4153ffd15a8ef3438. We will have to wait until the next CEF integration. Until then the workaround hack made by @MarcelGerber is our best bet.

nethip on 31 Aug 2015

I don't quite understand why this issue has been closed, and hasn't been fixed in 1.5.0. Can someone explain why this issue still exists?

thany on 27 Oct 2015

@thany Maybe because they've made a to-do list to work for?

danvim on 28 Oct 2015

If that's the case, then that list seems to greatly suffer from unbalanced priority. Not only because this is such an obvious and irritating issue, but also because it's existed for FAR too long (since version 1.1), and other OS-specific issues are still being solved without much delay at all.

thany on 28 Oct 2015

@thany And clicking into the todo list, it seems they are fixing the "scrolling speed too slow" problem? What the?

danvim on 1 Nov 2015

Even so, looking at this issue, I still think priorities and urgency of issues is unbalanced.

thany on 2 Nov 2015

Is this issue finally fixed in 1.6?
And if not, care to explain why?

thany on 20 Jan 2016

@thany Surprisingly, I haven't got the scrolling problem since I don't know when. :O

danvim on 21 Jan 2016

Perhaps because you forgot you installed an extension that works around the problem, like I have? :)

thany on 21 Jan 2016

This issue still appears to be present in 1.6.

Smiley43210 on 27 Mar 2016

👍2

Any update on a fix, after so many moons of no fix?

thany on 5 May 2016

@thany, there is no hope at this rate

doppl3r on 5 May 2016

Especially if the dev team keeps chucking out releases with obvious bugs like this remaining... Isn't it ridiculous that Windows users have to use a hack to get something mundane like scrolling to work sensibly??

But seriously, is there any dev out there that can elaborate on a time frame?

thany on 6 May 2016

Please find the following PRs which are going to take care of this issue.

Brackets: https://github.com/adobe/brackets/pull/12415
Brackets-shell: https://github.com/adobe/brackets-shell/pull/544

In order to fix this bug, we need to upgrade to later versions of CEF, which is a huge task by itself. If we don't see any issues around upgrading, this fix should make it to 1.7

nethip on 11 May 2016

👍2 ❤1

Weren't there some ideas floating around to switch to Electron? Or a similar framework that's built on top of Chromium, rather than CEF?

thany on 12 May 2016

Yes! you can find the fork here https://github.com/zaggino/brackets-electron. But dark theme is what we will have to forgo and that is one of the reasons why that fork is not mainstream.

nethip on 12 May 2016

I'm sure it can be done! Chrom(e/ium) itself is themable as well, after all. Anyway, I'll check it out when I'm not too busy doing actual work :)

thany on 12 May 2016

Sure @thany. I am not sure If chromium, out of the box, is themable to the level of what we have in Brackets. We had already done a round of investigation. But that was a while ago. May be things have changed by now. Please update your investigation results l, when you get a chance to look at it.

nethip on 12 May 2016

Here is the thread about dark theme in electron shell.

https://github.com/electron/electron/issues/1582

nethip on 12 May 2016

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)

MarcelGerber on 13 May 2016

Was this page helpful?

0 / 5 - 0 ratings