Change article header to "position: sticky"

Tiny Tiny RSS Development
22

Just updated in trunk and the changes look and feel great! The scrolling is noticeably smoother and looks better on the combined view compact theme.

Thanks guys @fox & @ctag

23

Just a quick note, this change seem to have “undone” the work on releasing the content, as now all videos, at least gyfcat, are loading and running as soon as the view is loaded and keeps playing even after the video has been read.
I didn’t have the don’t auto play html5 videos enabled, which is how I noticed the random music playing, enabling the plug-in stops the music…

24

you’re right, unpack observer should only work in expanded mode.

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

in expanded mode though some articles are unpacked on load, but not all. this seems to work properly.

25

I really like this change. It’s minor but makes for a much better user experience.

One thing I noticed while fixing a separate issue is that when scrolling in combined display mode without expanded articles, the [stuck] CSS effects are applied to headlines that are already read but not expanded. This is noticeable when scrolling a long list of read articles (e.g. Recently read feed) as you’ll see the top-most headline flicker white and have a thicker bottom border just before it scrolls out of the viewport.

I’ve put together a PR that I think fixes the issue. It moves the [stuck] CSS to only apply to div.cdm.expandable.active .header[stuck] and div.cdm.expanded .header[stuck]. This seems to fix the issue I described without breaking anything else. It also seems to removes the need to override the background to transparent for expanded articles because the new directives are more specific.

26

merged, thanks!

/20char

27

I am using v20.05-eae7961 with Chrome 81.0.4044.138.

I am in combined mode and use either “n” or “Ctrl+Down” to scroll articles. Sometimes I have to press “p” or “Ctrl+Up” twice to go to the previous articles.

I could not figure out if it depends on the lenght of the articles (previous, current or following). Seems like random.

Is it just me?

28

yeah, I’ve also noticed this.

29

Maybe I am wrong, but if the current article is “pure text” (has no media, images or video of any kind), you need to press twice to go to the previous one.

30

it’s a pixel offset issue somewhere. ‘p’ currently goes to beginning of current article if it starts offscreen and to the actual previous article if it’s not.

there should be a safe zone of a few pixels in there.

31

hopefully this should help: https://git.tt-rss.org/fox/tt-rss/commit/05a84ab778ee0bc5af3ee626ef87a2074d06c51a

spent an hour on a rather exciting journey into ridiculous scrolling-related bugs in microsoft chromeedge

then i opened google chrome and things immediately became less confusing

what i’m saying here is that i feel for people who do frontend for a living

32

I upgraded to v20.05-06d2c65 and I still notice that sometimes p has to be pressed twice in order to go to the previous article:

keyeventToAction n => next_article_noscroll
Headlines.js?1589727677:830 cur: 53058 next: 53068 prev:53059
Article.js?1589727677:327 setActive 53068 was 53058
AppBase.js?1589727677:200 keyeventToAction n => next_article_noscroll
Headlines.js?1589727677:830 cur: 53068 next: 53065 prev:53058
Article.js?1589727677:327 setActive 53065 was 53068
AppBase.js?1589727677:200 keyeventToAction p => prev_article_noscroll
Headlines.js?1589727677:830 cur: 53065 next: 53067 prev:53068
AppBase.js?1589727677:200 keyeventToAction p => prev_article_noscroll
Headlines.js?1589727677:830 cur: 53065 next: 53067 prev:53068
Article.js?1589727677:327 setActive 53068 was 53065

Hope it helps

33

I’ll poke at it a bit more later today.

34

https://git.tt-rss.org/fox/tt-rss/commit/8dc6b48ebd73b865c18e261a28f0e97ad304a39b

getting out of ideas here tbh

also, if you press ‘p’ while smooth scroll hasn’t finished yet (i.e. an article was half scrolled down at the moment and you were going back to top of it) it won’t register.

35

On my (unpublished) mobile plugin for TT-RSS I basically do the following when collapsing an article or moving to the next one:

If collapsing only:

  1. If the top of the article is anywhere in the viewport, do nothing, just collapse it.
  2. Else move the top of the closed article to the top of the viewport by queuing an event with requestAnimationFrame() or setTimeout() without a duration. Scroll offsets are determined inside the aforementioned handler. This gives the DOM time redraw, which I have found to be the single most important thing for this stuff.

If collapsing an open article and/or expanding a closed article:

  1. Wait until the next article is expanded and the existing article is collapsed. This can be done using requestAnimationFrame() or by using setTimeout() without a duration.
    (I’m using Bootstrap 3’s framework so it adds CSS classes to the element at each stage of open/close/expanding/collapsing; which makes it easier to know what’s going on.)
  2. When expanding an article, wrap the scroll handling in requestAnimationFrame() or setTimeout() without a duration.
    (Inside the handler, before scrolling, check if the article contains images (iframes probably apply here, too); if so, wrap in another setTimeout() handler for some random time (500 ms, this depends entirely on network speed and, unfortunately, not every browser supports binding an onload event to individual image tags); if there are no images, scroll to the top of the article.)

This logic typically works well. The reason for the stupid-crazy image handling is because if the article is the last in the article list and contains images, it won’t bring the content properly into the view if the images aren’t loaded. It’s not strictly necessary but it was annoying enough for me to code the extra bit.

36

i would rather suffer an occasional cosmetic glitch than go through all that :frowning:

i especially hate the whole settimeout-related thing.

37

I do not know if it might help (maybe not), but I noticed that if I log in using “low resources mode” (i.e. not loading images), keyboards n/p seems to be working perfectly.

38

i wonder if this makes it better or worse: https://git.tt-rss.org/fox/tt-rss/commit/2deb9c555e31ec36b430f69a1ff673d648b8cf4a

(i’ve added requestAnimationFrame based on @JustAMacUser post above).

e: i had some glitches specific to blink version in chromium edge which disappeared entirely with this.

40

Hi Fox,
Sorry to dig up this old thread. I just noticed on v20.10-83e08e0e2 the auto playing of all visible posts is back.

41

no more unpacking now, stuff loads as it becomes visible.

see here Loading image when scrolling with mouse wheel - Support - Tiny Tiny RSS: Community

(there’s video_no_autoplay plugin btw)

42

Sorry did see that thread, just didn’t link the two. Sorry for posting.

The no_autoplay plugin is awesome :slight_smile: