1

I’ve updated to this commit , and have the Scroll feature, but when the article is a long one, it will take some time to go to the next article.

So, dear developers, could you make a switch button if some one want to turn it off?

2

you should be able to easily override this in user css using something like this:

#headlines-frame.smooth-scroll, 
#content-insert { 
    scroll-behavior : auto ! important 
};
3

Thanks. It works!:kissing_heart:

4

Thanks. It might be good to make this a quick configure check box. I’ve always found this kind of smooth scrolling both slow but a bit hard on the eyes.

For others – Copy and paste the line fox provided into Preferences;General;Theme;Customize. Then hit the Save and Reload button.

5

This really needs to go, it makes the interface unusable in chrome when using a keyboard.

6

literally_unplayable_meme.jpg

the solution is right there above your post.

7

yes thats great for people that understand thats what it is causing the issue and I’d already made that change myself.

From a usability perspective why was the change made when it obviously makes the interface much worse?

8

protip: just because you personally don’t happen to like something, forum poster fruitcak, doesn’t make it “obviously much worse” or “unusable” or anything else, really.

you’re not going to get very far here if your non-arguments consist entirely of hyperbole.

both browsers that matter (i.e. firefox and chrome) have been smooth scrolling (by default) for several years now, this makes overall UI behavior more consistent with that.

9

If thats the case why does adding this change make scrolling in TT-RSS behaviour visually massively different in Chrome Version 78.0.3904.70 (Official Build) (64-bit) than scrolling in Gmail, Google Search results, Office 365, AWS Console, Oracle Netsuite, StackExchange, Jira, Intel, Jenkins, Google Docs.

If it was on by default as you claim why would setting it to smooth-scrolling instead of auto drastically change the behaviour?

Without the smooth-scrolling keyboard arrow up and down scrolls the window the same amount as a mouse wheel rotation, turning on smooth scrolling in this way results in arrow key browsing moving the screen about half the distance a mouse wheel click does.

Holding down arrow key with it set to auto (the actual browser default) results in smooth scrolling. Setting smooth-scrolling slowly rolls past at about one third to half the rate making the interface feel laggy.

I have a video of this that can be posted to a ticket showing how bad the keyboard navigation is now, as a primary keyboard user this makes the interface unusably laggy

10

i don’t use any of those applications and i don’t know if they have inline scrollable divs so i can’t answer this question.

it’s not enabled by default when you adjust scrollTop (using javascript) of an overflow-enabled div. it was on for everything else, i.e. wheel events, native pgup/pgdn (before tt-rss recently started to handle those via global hotkeys), etc.

continue twisting my words at your own peril, etc.

because it wasn’t smooth before, you instantly jumped to the offset when moving around. you can easily replicate this behavior at runtime by removing the necessary classname in browser console, i.e.

$("headlines-frame").removeClassName("smooth-scroll");

and using n/p etc hotkeys.

wheel distance entirely depends on whatever browser/platform you’re running, it’s outside of tt-rss control because it doesn’t trap wheel events.

actual scroll offsets were not in any way adjusted with this change, it jumps to exactly same offset only not immediately. the change is entirely cosmetic.

it is slower because it’s smooth, obviously. unfortunately, scrolling speed is not configurable using CSS, your browser decides that.

if you think pgup/pgdn is specifically slow this might be because we scroll by 90% of viewport height to keep some previously read stuff on screen so it would be easier to continue reading. this might be a bit different from previous browser-native pgup/pgdn handling, this was changed shortly before smooth scrolling and is not really related.

scroll distance is adjustable and can be extended, i suppose.

again, in this case, “auto” means “disabled”.

go ahead and upload it to youtube or something, i’ll take a look.

you’re one more literally unplayable meme from being probated.

11

i think the solution here is unbinding from default pgup/pgdn events. native handlers scroll a lot faster - for whatever unknown reason. other hotkeys (i.e. with modifiers) stay as they are.

unfortunately this means pgup/pgdn become dependent on focused element again.

https://git.tt-rss.org/fox/tt-rss/commit/008afb97a9c7dc1ef62e0e87fa73cf46aeb09f40

12

Hi.

After updating to v19.12-76dd74e0d, scrolling an article text in the preview pane has slowed down to about 5 lines per second. Used to be times faster.

Of the three browsers tested – Safari, Firefox, Chrome – only Safari is business as usual.

Tried tweaking CSS as suggested here, to no avail.

Is there any way to regain the scrolling speed?

VPS • Debian buster • PHP 7.3.11-1 • PostgreSQL 11.5

13

really now. platform? can you record a video?

try again with updated CSS rule.

14

platform?

Chrome: Windows 7, macOS Mojave
Firefox, Safari: macOS Mojave

can you record a video?

Here.

try again with updated CSS rule.

No change.

15

are you using three panel mode? then add this rule too:

#content-insert { scroll-behavior : auto ! important };

also don’t see scrolling behave like that on any devices i own. :man_shrugging: is that using keyboard, something else?

the only hotkey that kinda works like that is shift+up/down if you just press and hold it. i’m not sure why would anyone use it like this though because shift+pg/pgdn exists

e: it could be exempted from smooth scrolling although then you might run into similar issues with shift+pgup/pgdn because pressing continuously would interrupt the animation.

i suppose scrolling slowing like that when you press and hold the hotkeys is a legitimate issue.

16

https://git.tt-rss.org/fox/tt-rss/commit/e7dd634183154949fab7aa0b00844eb645cb87e5

i wonder if this would suffice as a compromise solution of sorts.

17

are you using three panel mode?

Yes.

#content-insert { scroll-behavior : auto ! important };

This did the trick. Thanks!

is that using keyboard, something else?

Yes, a keyboard.

the only hotkey that kinda works like that is shift+up/down if you just press and hold it.

Or N and P.

i’m not sure why would anyone use it like this though

Vim user here. Fingers on the home row. N and P scroll article text, n and p jump between articles. No need to reach for the arrows.

because shift+pg/pgdn exists

And what are these supposed to do? Don’t seem to work on my keyboard. Nor can find any mention of them in Shift-?.

18

you sure you’re on latest trunk? because those two hotkeys should be documented in the help dialog.

19

Indeed. Just updated and can see them now. A bit jerky to my taste, one press covers too much ground. Still prefer the old way or the above #content-insert solution.

20

An interesting effect: scrolling starts slowly (the ‘smooth’ way) but then speeds up.