I'm going to start by describing a solution for current Flarum version, but by researching this I have discovered Flarum's code actually isn't doing what is intended, so the behavior might change in a future version if we fix the inconsistencies.
I think the OP is referring to the behavior that if you scroll down in the discussion list, and then change tag, Flarum will scroll back to the top, but not enough to reveal the hero. However if you change tags without scrolling down, the page stays at the top.
This is kind of intended behavior and implemented here https://github.com/flarum/core/blob/v1.1.1/js/src/forum/components/IndexPage.js#L95
The easiest way to override it is probably with something like this:
extend(IndexPage.prototype, 'oncreate', function () {
$(window).scrollTop(0);
});
However this will also override the logic that handles returning to the previous scroll position when pressing back from a discussion (line 100 and next in the source).
It's difficult to only override line 95 without overriding the full oncreate method. Adding an if for lastDiscussion should reduce the risk of conflict:
extend(IndexPage.prototype, 'oncreate', function () {
if (!this.lastDiscussion) {
$(window).scrollTop(0);
}
});
There might be another way to manipulate that code by modifying app.cache.heroHeight before the method runs in an override() call, but that seems a bit overkill.
Now the Flarum inconsistency. Scrolling back to the just below the hero isn't actually what line 95 is supposed to do. The bit about app.cache.scrollTop is supposed to scroll back to the exact same scroll position as last page, not the top of the discussion list. The code for oldHeroHeight + heroHeight is only there to account for the change of height of the page, but not to calculate where the hero actually ends.
The real behavior is that when you change "filter" (changing tag, or going to subscriptions, etc.) the page should stay exactly where it was visually, with only the discussion list changing. Currently this can only be experienced if you come back to the page that has the discussion list pre-loaded into the single page app (for example, going to the tag list, then coming back to the discussion list. You'll have the exact same scroll)
The reason it doesn't work is because at the time $(window).scrollTop() is called, the discussion list isn't loaded yet. So the value passed to scrollTop() exceeds what is possible, and the page just scrolls down as low as it can.
And it so happens that "as low as it can" is just below the hero, because of this line https://github.com/flarum/core/blob/v1.1.1/js/src/forum/components/IndexPage.js#L87 that sets the page height as window height + hero height.
We'll need to discuss what to do in Flarum core, we can either:
- Fix
app.cache.scrollTop behavior to work as the code intended. This will require making the page taller during discussion loading with either a placeholder or by manipulating #app min-height even more
- Drop
app.cache.scrollTop behavior and scroll to bottom of hero, which the current behavior in practice
- Drop
app.cache.scrollTop behavior and scroll to the top of the page
The current scroll-to-bottom-of-hero behavior doesn't seem to have any reasoning behind it since it apparently isn't the intended behavior. No comments in the code mention this as the intended feature.
There's also a bunch of code to handle scroll inside of the discussion list for when it's in the side drawer, but that code doesn't seem to affect the global page scroll of the homepage.
