Feature Request: Add an option to disable the automatic jump to the last post after replying

Hi everyone,

I’ve recently spent some time searching through old topics and discussions on Meta and other Discourse-based forums, and I found that many users over the years have repeatedly raised the same concern:

After posting a reply or closing the composer, Discourse automatically jumps to the very last post in the topic.

For quite a few people—including myself—this behavior is actually disruptive rather than helpful.

Why it’s causing issues

Based on what many users have expressed, the common problems include:

  • When replying in the middle of a long thread, the composer closes and the view suddenly jumps to the bottom, forcing you to scroll all the way back to continue reading where you were.

  • If you’re replying while catching up on older messages, this auto-jump breaks the reading flow.

  • Some users even thought this might be a bug, because the jump happens so quickly that it feels unexpected and unintuitive.

  • A number of past discussions indicate that people have tried workarounds, scripts, or hacks, but nothing works reliably or officially.

In short, while auto-jumping to the newest post is useful for some users, it’s clearly unwanted for many others depending on their reading habits or workflow.

Feature Request: Please make this behavior optional

From reviewing past threads, it seems that:

  • There is no built-in setting to disable this auto-jump

  • There is no official plugin that provides a toggle

  • Admins and users currently cannot control this behavior at all

So I’d like to request that Discourse provide either:

A user preference, such as:

“After posting or closing the composer, stay at the current position (do not jump to the last post).”

or

A site-wide/admin setting, such as:

“Enable/disable automatic scroll to the latest post after replies.”

This would allow different communities (and individual users) to choose whichever interaction model better fits their reading style. It also aligns with the design philosophy of Discourse, which usually allows customization of reading flow behaviors.

Why an option would benefit everyone

  • Users who like the auto-jump can keep it as is

  • Users who dislike it can turn it off

  • Forum admins can set defaults that match their community’s needs

  • No one would need to rely on fragile custom JavaScript or browser userscripts

  • It improves accessibility and reduces sudden movement that may be uncomfortable for some readers

Given how many people have raised this issue over the years, adding a configurable option could significantly improve UX for a large portion of the community.

If I’ve missed an existing setting or plugin, please feel free to point me to it — but based on what I’ve found, it doesn’t seem like such an option currently exists.

Thanks for considering it, and I’d really appreciate any insights from the team or other plugin developers.

1 Like

Won’t it be confusing for you to post something and then be left dozens of posts above your post with no indication that it’s been posted? Why not just keep reading so you can comment on the rest of the posts if you want to?

2 Likes

Thanks for the explanation! Let me clarify my actual use case, because the current behavior still creates a real problem for me.

Imagine this scenario:
I start a discussion thread, go to sleep, and the next day I wake up to find more than a hundred replies. Many of them are interesting, and I want to reply to some of them while reading through the thread.

Here’s the issue:

When I read a reply somewhere in the middle of the topic and respond to it, after I send my reply Discourse immediately jumps all the way to the very bottom of the topic.
But the conversation is not real-time — people might not reply again until hours later. I don’t need to be taken to the latest post. I just want to continue reading the rest of the replies in order.

What I really need is simply:

  • A clear indication that my reply was successfully posted

  • Without losing my current reading position

  • So I can naturally continue reading the next replies in sequence

Right now, after the forced auto-jump, I have to manually scroll back and try to remember where I was, which is tedious and breaks the reading flow.

This is why an option to stay at the current scroll position after posting would be extremely helpful.
The auto-jump is useful for some workflows, but in cases like mine, it just gets in the way.

There are thousands upon thousands of words about this at Will disable_jump_reply make a return? and related topics.

TL;DR You can hold Shift when posting to prevent the scroll.

1 Like

Thanks for the tip! I didn’t know about the Shift + Reply behavior — that does help in some situations.

That said, I still feel this would really benefit from a proper setting or user preference. Using a modifier key every time isn’t very discoverable, and it’s easy to forget, especially for less technical users who might not even know such shortcuts exist.

One of the things I really appreciate about Discourse is the high degree of freedom it already offers — users can customize many aspects of how they read, navigate, and interact. In my opinion, that freedom is exactly what makes Discourse such a great platform. With this specific behavior, it would be wonderful if users could simply choose their default preference:

  • automatically jump to the last post after replying, or

  • stay at the current position and continue reading

Having a clear default plus the ability to adjust it would make the behavior more intuitive and more accessible. For example, in my own browsing habits, I tend to open most topics from the homepage in new tabs because modern computers have plenty of memory and closing tabs is often faster and more convenient than navigating back and forth. It’s just one example of how different users value different workflows.

So my general philosophy is: the more user choice, the better.
If a feature has multiple reasonable behaviors, letting the user decide—rather than forcing everyone into one path—usually leads to a better experience for all. It also means users like me wouldn’t need to create small scripts or plugins just to restore a workflow that feels natural to us.

Thanks again for the helpful reply, and I hope this might still be considered as a potential optional setting in the future.

1 Like

Please read Will disable_jump_reply make a return?. It was a user preference and it was removed.

2 Likes

:heart: Thanks for the pointer — I’ve now read through the whole “Will disable_jump_reply make a return?” topic.

I understand the reasoning behind removing the old disable_jump_reply preference:
it was broken at the time, very few people were using it, and Discourse generally tries to avoid accumulating lots of global user prefs. I also see the design philosophy you described there — using the auto-jump as a way to encourage people to read the full topic before replying, with more “expert” workflows hidden behind things like modifier keys or advanced options.

The Shift + Reply shortcut definitely helps in some cases, and I appreciate you mentioning it. The problem for me is that:

it’s not discoverable at all unless you’ve read that specific Meta topic or someone tells you,

it adds mental overhead to remember a special key every single time, and

when you’re catching up on long topics across multiple Discourse forums, being yanked hundreds of posts away from where you were reading still feels like a pretty heavy “punishment” for a simple reply.

One of the things I personally love about Discourse is exactly its flexibility:
as an admin or as a user you can tweak a lot of details to match your own reading and navigation habits. From that perspective, this feels like an area where a small amount of extra configurability could go a long way, without turning the UI into a wall of options.

For example, any of these would already be a big improvement:

A visible “reply without jumping” option in the UI (even if it’s considered an advanced / expert action),

Or a user-level / site-level toggle hidden behind an “advanced” section, so that people who really care about this behavior can opt out of the jump once, instead of relying on a hidden shortcut forever.

I completely understand the concern about having too many prefs, and I’m not asking to bring back every obscure setting. I just wanted to share the view from someone who spends a lot of time replying while reading through older posts:
for this particular behavior, the cost of not having a clear, discoverable choice feels higher than for many other preferences.

In any case, thank you again for the explanation and the Shift tip — it’s very helpful to know the background, even if I still hope this might be reconsidered as some kind of optional or “expert” setting in the future.

1 Like

Thanks again — and interestingly, when I asked the same question on a few other Discourse-based forums, several users also had no idea that holding Shift prevents the jump. So it’s clearly not a very discoverable behavior.

On the bright side, now that I know about the Shift mechanism, writing a small plugin or theme component tomorrow should be fairly straightforward. It actually gives me a cleaner implementation approach, since I won’t need to rely on heavy DOM mutation observers to counter the auto-scroll — I can hook into the same logic instead.

Anyway, appreciate the information. Even if this remains an “expert-only” behavior, I’m glad I finally understand the underlying mechanism well enough to extend it properly.

2 Likes