Reading progress (posts read) not advancing for keyboard-only or non-scrolling clients

[lechynte-ub]

What I noticed

I have been reading the forum with a keyboard-only workflow (no mouse scrolling, Vimium-style navigation). My profile stats for “posts read” barely moved even after spending real time in threads — while “topics entered” went up normally.

So I ran a controlled test to find out why.

Test

Picked a topic I had never opened (/t/88016, 5 posts), and watched last_read_post_number from /t/88016.json after each step.

Step	last_read_post_number
Not opened	(none)
Opened the topic, stayed on the page ~55 s, no scrolling	1
Scrolled to the very bottom, waited 6 s	1
POST /topics/timings with timings for posts 1–5	5

So opening a topic marks post 1 as read, but scrolling alone does not advance reading progress — at least not for me.

What I think is happening

Discourse tracks per-post reading time via ScreenTrack, which uses viewport visibility to decide which post the user is “on”. In a keyboard-only or headless client, posts never enter the viewport the way scroll-based clients make them enter, so per-post timing never accumulates and last_read_post_number stays put.

MessageBus is fine, by the way — MessageBus.status() returns started and it has an active client id and subscriptions. This is not a connectivity problem.

Manually sending topic_time / timings[N] to /topics/timings does record correctly, which is consistent with the client-side theory above.

Why I’m posting this

Two reasons:

1. Stats accuracy. If reading progress depends on scroll events, then users who navigate by keyboard — or use accessibility tools, or read via any non-standard client — will see the same flat stats I did. That may matter for trust-level progression, which is partly based on reading.

2. A documentation question. Is scroll-based tracking the intended behaviour, or is it a side effect that happens to work for most people? I could not find it documented anywhere.

What would help

• A confirmation from someone who knows the internals of ScreenTrack on whether scroll events are the trigger.
• If scroll is required, a note in the user documentation that reading progress is scroll-based, so keyboard-only users know their stats won’t reflect actual reading.

My setup

• Ubuntu 26.04, Firefox, keyboard-only navigation (Vimium). No custom userscripts touching the page.

[rubi1200]

Thanks for posting this excellent and quite thorough analysis.

What you are seeing is, in fact, by design in the Discourse software.

Based on a conversation with ask.discourse.com, here is the longer answer:

@DiscourseHelper

Is scroll the trigger? Yes — mostly.

The definitive technical write-up is by @sam: How does post tracking work in Discourse. From it:

“When a topic page scrolls it will inform the screen tracker what posts it has in view AND which of these posts have been read.”
“If 3 minutes pass and you have not scrolled at all, we disable this subsystem until stuff scrolls again”

So yes — screen-track.js only learns which posts you’re “on” when a scroll fires. If nothing scrolls, per-post timing never accumulates for posts 2..N. That part of your hypothesis matches the implementation.

But there’s a second requirement: minimum on-screen time

Your step “scrolled to the very bottom, waited 6 s → still 1” is explained by this rule from the official reference guide Understanding stats for ‘topic views’, ‘posts read’, and ‘reading time’:

Q: If I open one topic with a lot of replies and scroll down quickly, will I have read all the posts?
A: No, Discourse requires a post to be on the screen for at least a few seconds before counting it as read. The exact time varies depending on the length of the post.

So it’s not “scroll → instantly read.” A post must (a) enter the viewport (via a scroll event updating the in-view list) and (b) stay visible long enough for the per-post threshold (the tracker uses a WPM-style calculation, so long posts need more seconds than short ones). Six seconds at the bottom simply wasn’t enough for those posts — not proof that scroll events were ignored.

Is this intended behavior? Yes.

The FAQ above confirms it’s deliberate: “posts read” is meant to reflect posts you actually paused on, not ones you flew past. It’s consistent with the 3 minutes idle → subsystem pauses design. You’re right that it isn’t documented in the user-facing docs — it’s documented in the dev/reference guides only. There’s also an open feature request to make the “marked as read” threshold customizable: Allow customizing when posts are marked as read.

Keyboard-only / accessibility implication

Your inference is correct: any client that moves through posts without generating scroll events (or that hops too fast for posts to accrue the threshold) will under-report posts read and last_read_post_number. Discourse’s own j/k navigation does scroll the window, so it should inform screen-track — but rapid j/k hopping generally causes posts to be skipped as “read” for the same time-threshold reason, which is a known behavior.

And yes, this can matter for trust levels — TL1 includes a “read posts” requirement (default 30) as noted in When is a post considered “read”?.

Suggested follow-ups

• If you’d like keyboard/accessibility navigation to count toward reading stats (e.g. via an IntersectionObserver-based approach instead of relying on scroll), post that as a feature request on meta — there isn’t an existing setting for it today.
• For the documentation gap, a docs/UX thread on the reference guide would be reasonable; nothing currently documents that reading progress is effectively scroll-driven.

Short version: your diagnosis is right, with the caveat that scrolling is necessary but not sufficient — posts must also remain visible for a few seconds (per length) to be counted as read. That threshold, not scroll alone, likely explains your 55s no scroll → 1, scroll+6s → still 1 result.

I suggest you open an account over at Meta Discourse and file a bug report/feature request.

Thanks for being part of the community.

[lechynte-ub]

Thanks for the thorough reply, and for the correction — you’re right, and I had part of this backwards.

The part I got right: scroll does drive the tracker. That matches the official reference (“When a topic page ‘scrolls’ it will inform the screen tracker what posts it has in view AND which of these posts have been read”), so the ScreenTrack/viewport hypothesis holds.

The part I got wrong: my inference from “scrolled to the bottom, waited 6 s → still 1”. I read that as scroll events being ignored. The real explanation is the minimum on-screen time requirement — a post has to stay visible for a few seconds, scaled by post length, before it counts as read. Six seconds at the bottom simply wasn’t long enough for those posts. My test couldn’t distinguish “scroll ignored” from “scrolled but not long enough,” and I jumped to the first one.

That’s a good reminder to design the experiment before reading the results. If I’d waited 30+ seconds at the bottom instead of 6, the two hypotheses would have separated.

Appreciate the pointer that this is by design and only documented in the dev/reference guides, not the user-facing ones. And the accessibility angle is the part I actually care about — if reading progress is effectively scroll-plus-dwell-time driven, then any client that moves through posts without generating scroll events under-reports. That’s worth a feature request on Meta.

I’ll take your advice and open an account over at Meta Discourse to file it there, since there’s no existing setting for it. That’s the right place for it rather than here.

Thanks again for the references.