I enabled nested replies for all topics (Horizon theme) and hit a state bug I can now
reproduce, on both mobile and desktop.
When I open a topic, read it, and then jump to another topic via the suggested/related
topics block (so client-side navigation, no reload), replies from the topic I just left
sometimes stay on screen — rendered nested under the first branch of the new topic.
They even attach under a post that’s been deleted in the new topic. It doesn’t clear if
I keep navigating to more topics; only a full page reload gets rid of it.
One important detail: it’s intermittent. The first hop through the related block is
usually fine, and I can click through it several times with no problem. It only seems to
show up after navigating through the related topics block two or more times in a row.
Steps to reproduce:
Open a topic with nested replies.
Open another topic through the suggested/related block (no reload), and keep doing
this a few times in a row.
After two or more consecutive hops through the block, replies from a previous topic
appear nested under the first branch of the current topic, sometimes under a post
that is deleted there.
They persist across further in-app navigation until a hard reload.
There’s no JS error in the console, so I went into the Network tab, and it looks like the
previous topic is simply never torn down:
The inspected page is topic 724 (/n/vibriruet-pri-troganii…/724?sort=old).
While I’m on 724, a request for the previous topic’s data is still in the log:
509.json?sort=old&track_visit=true.
The live message-bus poll still has Referer …/n/pinki-tolchki-…-na-nissane-kube/509
— i.e. topic 509’s message-bus subscription was never re-pointed at 724.
So it really seems like the nested route doesn’t reset the post stream / message-bus
subscription of the topic you came from on client-side navigation. First noticed on
mobile, but it behaves the same on desktop.
Discourse version: 2026.6.0-latest (27f76aa897)
Happy to attach a screen recording or dig further if that helps.
It reproduces only on Horizon - on Foundation I didn’t see the reply branch carrying
over between topics.
But I don’t think it’s simply absent on Foundation; it looks more like it comes down to
how navigation works there. The difference I noticed:
Horizon: when I click a related topic (or open any topic from the list), the topic
appears instantly, with no loading indicator. This instant navigation is exactly when
the branch carry-over shows up, after 2+ clicks in a row.
Foundation: the topic also appears instantly at first (same as Horizon), but then after
~200-400ms a loading screen with animated dots appears and the topic loads again - so there’s a second, self-triggered load right after the fast open.
So it seems the bug surfaces specifically because of the “instant” navigation, where the
previous topic’s state isn’t reset. On Foundation that follow-up load apparently resets
the state and masks the problem. In other words: on Horizon the instant nested-topic
navigation doesn’t reset the previous topic’s post stream / message-bus subscription,
whereas Foundation’s flow does it via that second load.
Separately, while testing on Horizon: in the nested view I occasionally get a tiny layout
shift. I open a topic, start scrolling down, and as the screen reaches the replies a quick
micro-shift can happen - not every time, but fairly often. Might be related, might be a
separate minor thing; flagging it just in case.
A separate, minor thing I ran into - not sure if it’s nested- or Horizon-specific, but it didn’t happen in flat mode: the topic stats row is laid out incorrectly in one edge case. When a topic has too few users to show the “users” count and no reading time is shown, the views counter drops onto a single line and is rendered in a different colour, instead of the normal styled stat block with the number. Screenshot 1 - normal. Screenshot 2 - the edge case. Happy to split this into its own topic if you’d rather keep the bugs separate.
I think I have a fix for your Horizon issues. I’ll include in an upcoming PR that affects the mobile nested topic view quite a bit. Hoping to have it out today.
Thanks for jumping on this so fast! I found the fix in #40548 (“fix nested post registration teardown”) and saw the PR is still in draft, so no rush at all.
Just wanted to check in - is there a rough idea of when it might land? And I’m happy to test it on my instance once it’s ready, if that’s useful.
I’ve included that fix in a larger mobile UX refactoring that I’ve been working on. I’m just doing final QA to make sure I’m not breaking anything unexpectedly. I’m hoping to have it merged today or tomorrow.
Merged the PR let me know after you update if things are looking good. I didn’t forget about the weird formatting of the views label. Will address that shortly.
Thanks for getting #40652 in! I’m now on 2f2676180 with #40652 in the tree, did a full ./launcher rebuild app, and checked in incognito, so it’s not a cache thing. The carry-over is still happening though.
How it repros for me (sort set to oldest first): the first branch and the 2 replies under it always follow into the next topic and show up under the first branch there, as long as I move between topics without reloading. A full page reload clears it.
Unrelated idea, not a bug: when someone replies to their own post, maybe don’t add another nesting level for it and just put it below at the same level. Some apps do it that way and it keeps threads from getting too deep. Just a thought.
let me know after you update if things are looking good. I didn’t forget about the weird formatting of the