Scrolling sometimes reverts to being too fast #11083

thany · 2015-05-11T12:44:36Z

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.

thany · 2015-05-11T16:12:35Z

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 · 2015-05-12T09:07:57Z

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?

marcelgerber · 2015-05-12T17:27:42Z

You can see what we did to fix this bug here: #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)

thany · 2015-05-13T08:19:29Z

For the moment, I've got these installed:

brackets-display-shortcuts
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

marcelgerber · 2015-05-13T12:10:30Z

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.

thany · 2015-05-13T15:16:57Z

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 · 2015-05-13T15:28:45Z

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.

marcelgerber · 2015-05-13T18:54:22Z

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.

thany · 2015-05-14T11:40:13Z

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?

marcelgerber · 2015-05-14T11:45:19Z

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.

thany · 2015-05-18T12:09:18Z

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 :)

marcelgerber · 2015-05-19T19:04:00Z

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 · 2015-05-19T19:05:42Z

(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)

drozzy · 2015-08-25T04:48:09Z

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!

doppl3r · 2015-08-25T23:23:42Z

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

danvim · 2015-08-30T08:02:29Z

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.

marcelgerber · 2015-08-30T08:56:15Z

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

thany · 2015-08-31T07:47:28Z

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

marcelgerber · 2015-08-31T09:20:25Z

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.

nethip · 2015-08-31T09:39:51Z

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.

thany · 2015-10-27T17:20:39Z

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?

danvim · 2015-10-28T13:10:02Z

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

thany · 2015-10-28T16:04:14Z

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.

danvim · 2015-11-01T12:49:36Z

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

thany · 2015-11-02T12:12:03Z

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

thany · 2016-01-20T19:06:56Z

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

danvim · 2016-01-21T05:50:51Z

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

thany · 2016-01-21T09:40:14Z

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

minimusubi · 2016-03-27T02:09:39Z

This issue still appears to be present in 1.6.

thany · 2016-05-04T23:51:24Z

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

doppl3r · 2016-05-04T23:53:50Z

@thany, there is no hope at this rate

thany · 2016-05-06T09:48:27Z

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?

nethip · 2016-05-11T19:07:47Z

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

Brackets: #12415
Brackets-shell: adobe/brackets-shell#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

thany · 2016-05-12T08:35:15Z

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?

nethip · 2016-05-12T08:38:39Z

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.

thany · 2016-05-12T16:12:53Z

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 :)

nethip · 2016-05-12T16:20:05Z

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 · 2016-05-12T16:34:43Z

Here is the thread about dark theme in electron shell.

electron/electron#1582

marcelgerber · 2016-05-13T15:19:45Z

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 self-assigned this May 12, 2015

thany mentioned this issue May 14, 2015

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

Closed

This was referenced Aug 28, 2015

Make sure the Windows scroll fix always catches the spurious second event #11638

Closed

Scrolling on Windows distance inconsistence #11627

Closed

abose mentioned this issue Oct 27, 2015

[Performance] Scrolling performance #11105

Closed

3 tasks

thany mentioned this issue Dec 28, 2015

Not all folders are being excluded JonathanWolfe/file-tree-exclude#30

Open

marcelgerber closed this as completed May 13, 2016

marcelgerber added this to the Release 1.7 milestone May 13, 2016

This was referenced Aug 30, 2021

[CLOSED] Scrolling sometimes reverts to being too fast brackets-archive/bracketsIssues#9711

Open

[CLOSED] [Performance] Scrolling performance brackets-archive/bracketsIssues#9726

Open

Scrolling sometimes reverts to being too fast #11083

Scrolling sometimes reverts to being too fast #11083

Comments

thany commented May 11, 2015

thany commented May 11, 2015

thany commented May 12, 2015

marcelgerber commented May 12, 2015

thany commented May 13, 2015

marcelgerber commented May 13, 2015

thany commented May 13, 2015

thany commented May 13, 2015

marcelgerber commented May 13, 2015

thany commented May 14, 2015

marcelgerber commented May 14, 2015

thany commented May 18, 2015

marcelgerber commented May 19, 2015

marcelgerber commented May 19, 2015

drozzy commented Aug 25, 2015

doppl3r commented Aug 25, 2015

danvim commented Aug 30, 2015

marcelgerber commented Aug 30, 2015

thany commented Aug 31, 2015

marcelgerber commented Aug 31, 2015

nethip commented Aug 31, 2015

thany commented Oct 27, 2015

danvim commented Oct 28, 2015

thany commented Oct 28, 2015

danvim commented Nov 1, 2015

thany commented Nov 2, 2015

thany commented Jan 20, 2016

danvim commented Jan 21, 2016

thany commented Jan 21, 2016

minimusubi commented Mar 27, 2016

thany commented May 4, 2016

doppl3r commented May 4, 2016

thany commented May 6, 2016

nethip commented May 11, 2016

thany commented May 12, 2016

nethip commented May 12, 2016

thany commented May 12, 2016

nethip commented May 12, 2016

nethip commented May 12, 2016

marcelgerber commented May 13, 2016 • edited Loading

marcelgerber commented May 13, 2016 •

edited

Loading