precisely half a page/set pixel amount respectively

Up to now, all scroll* commands share a same part of source code and will always "continue to scroll" if only a key is being held down.

even when I barely tap the button I am getting inconsistent scroll length

It's a bit strange. This means your keyboard has a much smaller delay than 560. When scrolling pixel by pixel, Vimium C will do a first scrolling action and then wait for a while, and it will do a second one if only: either a timer of 560ms ends, or a "repeated" keyboard event is sent by your browser.

Please note that [560, 33] is not what Vimium C gets from your system, but in fact an option which need you to update its value manually, so that Vimium C's scroller can work better. This option is added just because Vimium C can not asks your browser for such information.

precise scrolling would help

You may turn of "smooth scrolling" in a single key mapping, and it will be like:

map j scrollPxDown smooth=false

BTW, in "smooth scrolling" mode and when a new scroll* command gets triggered, Vimium C will always abort old scolling tasks and only execute the latest one. So you can not enable both count=100 and smooth=true to implement what you want in the first comment.

Maybe I can add another option to ignore "repeated" events which looks "too near", compared with 560ms, into a future version of Vimium C.

Thank you! The page scrolls precisely now.
In case anyone needs these:

map j scrollDown smooth=false
map k scrollUp smooth=false
map d scrollPageDown smooth=false
map u scrollPageUp smooth=false

When scrolling pixel by pixel, Vimium C will do a first scrolling action and then wait for a while, and it will do a second one if only: either a timer of 560ms ends, or a "repeated" keyboard event is sent by your browser.

Does this only apply with smooth=false? I have set delay/repeat to [300, 50] which is my computers value, and the scrolling events are still inconsistent/repeated with map k scrollPxUp count=100 and pressing the key for as short a time as possible (I would guess <50ms). When in a text box my characters repeat as intended, every 50ms after a 300ms delay.

Am I correct in thinking smooth is supposed to go a precise distance, but just interpolate between the values instead of instantly jumping? That would be the best imo.

I am content with smooth scrolling off though so no worries here.

do a first scrolling action and then wait for a while is ture only when smooth is true (smooth's default value is the value of Use Vimium C's smooth scrolling option).

delay/repeat is only to decide when it should stop even without any further repeated keydown key event or keyup event.

I think there's some issues in your browser itself - appearently it sent repeated keydown or keydown but repeated=false events too early (than after 300ms). In fact, Firefox + Linux-like systems "often" have such compatibility issues. If the events it sent during your tests are repeated, then a future wait: number option should help; if it sent too many keydown but repeated=false events, then it may be related about a bug of Firefox (philc/vimium#3386), and there's nothing I can do with it.

When smooth is false. Vimium C executes wanted scrolling step "at once", and then the scroll* gets finished. So a further keydown event will make Vimium C executes a new scrolling command again (with a same step).

Hello, Vimium C v1.96.0 has been released on Firefox Add-Ons, and you may add wait=500 to make scroll* always wait for 500ms - firstly-spent-time before scrolling again.

Thank you for the quick update! It works well for me now and is much more precise. I noticed there is still a bit of imprecision but not bad at all compared to before.

It seems like the distance is determined by the length of the initial key tap. It will scroll half a page plus up to maybe 5 extra pixels depending on length of press. I tried to add a video but it said the mp4 was corrupt so I will try and figure that out.

I am very happy with the way it is now though, I thought I would just let you know. Feel free to close or if you want to get to the bottom of it I can give you any info you need.

Hello every one.
same issue here, I have read the thread.
and turned off the smooth scrolling.
Not the best experience, but I am trying to tweak it a bit.
Scrolling was not an issue before. I think after a certain update the issue appears.
Any new updates here?
PS. if you want I can make a screen cast about the issue.
when I press j or k, it goes further than what I want.
PS. after turning the extension Off and On again, it will disappear.

I noticed that when I define e.g. map <c-o> scrollPxUp count=400 smooth=true, then the first key press will scroll 400... when I hold the keys then, the scrolling will continue, but slow down considerably. When using map <c-o> scrollPxUp count=400 smooth=false, the speed is constant.

I'm not sure that's the same as what the original author described. But it got me a little confused.

Vimium C will reduce/increase scrolling speed to near 150pixels per 16ms.

Is there a way to change these variables?

Update: the near 150 pixels is too complicated to describe it in short ...

1. there's a concept of amount, which means expected pixel distance (when no keys are holding on)
2. there's duration, which means how long it will take to scroll by amount (for the first time), and duration is computed from amount, with a minimum of 100ms
3. if a key is holding on and scrolling continues, Vimium C will increase / reduce amount, to make it nearer to 150 pixels

• 1. the changed value will also be limited into [0.5 * initial amount, 1.6 * initial amount]
• 2. Vimium C changes amount every (at least) 50ms

5. Vimium C executes a real scrolling everytime a screen refreshes, so the real scrolling step is amount * (1000ms / duration) / screen fps.

@hasufell Up to now there's no way to change the logic. It seems good enough - there're few complaints about this in the origin project, Vimium (see https://github.com/philc/vimium/issues).

For others, there seems indeed a logic issue which may make Vimium C scroll longer. I'll try to fix it. The root cause is the logic doesn't use .wait option, but it reads the "key up" event, so if a key is holding on for a (small to humans but big enough) while, it will scroll a bit longer.

Hello all, Vimium C v1.96.6 has been available on Firefox Add-Ons and Chrome Web Store. Its updates about scrolling are:

1. slightly slow down the default scrolling duration: from 100ms to 120ms

• 1. the original project Vimium always uses 100ms, and Vimium C followed this
• 2. but Vimium C once "improved scrolling" and start scrolling animation about 17ms earlier than Vimium, on a 60fps screen
• 3. during tests of myself, Vimium C often finished work just before I moved my finger up, so it scrolled by 1-2 frames again

2. the duration now is configurable on Vimium C Options, and it can be in 50ms ~ 1200ms
3. when Vimium C finds the total distance will arrive at "amount pixels" in a frame, then the real step will be limited into amount - totalFinishedDistance

• 1. this may have a impact that scrolling slows down only in a single frame, if a user keeps j / k holding on
• 2. but I think this impact doesn't matter

4. so you may give it a value which is "usually long enough" for you to press down a key and release it

• 1. for myself, it's 120ms, and you may try 150 or bigger values
• 2. the cost is Vimium C will scroll slower, since the speed is amount * (1000ms / duration) / screen fps and duration increases.

Hello Vimium C v1.97.0 has been published on Firefox Add-ons, and it tries to guess monitor refreshing rate (FPS) to generate scrolling steps.

I'm closing this issue. If any new problem is found, fell free to reopen it.

I've experienced since today (7 June, 2022) a drastic change in how smooth scrolling works on both Brave and Chrome - I don't know how frequently Chrome updates extensions, but the most recent update since I've noticed the change in behaviour is here (5 June, 2022): 554f1b1

I don't recall any OS updates between using my computer yesterday and today.

I'm not sure if an update in Vimium C enabled smooth scroll for me in both browsers or not.

Observations

Before:

• smooth scroll with u or d would scroll approximately half the viewport height when the browser is maximised
• smooth scroll with j or k would scroll a few hundred pixels

After:

• smooth scroll with u or d scrolls a much longer distance, moving unread content below the end of the viewport to above the viewport
• smooth scroll with j or k scrolls 4 or 5 times as far as without smooth scroll

Setting repeat delay to the maximum with smooth scroll enabled doesn't appear to have an impact on the scroll distance.

Trying to press d or u as fast as I possibly can does seem to reduce the scroll distance a little.

Screencast

Settings

OS:

Display:

Vimium Settings:

vimium_c-20220607_112046.json.zip

Workaround

Disabling smooth scroll restores the previous scroll behaviour for me

Sorry I'll test it today.

I am also experiencing the issue mentioned by @larrybotha. For me, on my 4k external monitor, everything feels the same as before. However on my MacBook Pro's built-in screen (16-inch M1 MacBook Pro) scrolling looks just like @larrybotha's screencast and the workaround (disabling smooth scrolling) works.

@larrybotha @jaywonchung Thanks for your report. I've found the root cause and made a new unstable version to fix it and the bug of X (restoreTab) failing: vimium_c-1.98.1-chrome-ebe5e49-mod.zip . And the usage of Zip packages is https://github.com/gdh1995/vimium-c/wiki/Test-a-zip-package .

The root bug is Vimium C tries to guess screen refresh rate, but the logic is wrong when FPS is between 95 and 149. And this explains why it still works correctly on a 4k + 30/60fps monitor.

In the web-store version of v1.98.1, there're a trick to force Vimium C not to guess FPS:

1. open Vimium C Options page (chrome-extension://hfjbmagddngcpeloejdejnfgbamkjaeg/pages/options.html)
2. press F12 (on Win) / ⌘ + Option + i (on macOS) to open the browser's DevTools window, and switch to Console
3. type the code below and press Enter to execute it

chrome.storage.local.set({keyboard: [560, 33, 1]})
chrome.runtime.reload()

• 1. the 560 and 33 can be replaced with the real numbers of your system keyboard, just as described by the Keyboard settings option on Vimium C Options
• 2. please note that v1.98.1 has a bug and then you can not add , 1 into Keyboard settings and save the option directly. I'll fix it soon

This trick is not perfect - it may fail if you hold on a key to scroll longer.

And when v1.98.2 is updated, please remove the ,1 on Vimium C Options, to make it scroll more uniformly.

@gdh1995 excellent, thanks for all the hard work

Smooth scrolling is working with the additional keyboard config - I see the sensitivity to the duration of a key press.

Thanks again, looking forward to the 1.98.2 release

Upgraded to v1.98.2, and things work perfectly. Thanks a lot!!