I can confirm this for Firefox 29; comments in Village Pump say that there is no issue in Firefox 28.

...and clicking the browser's address bar and pressing Enter fixes the problem.

Another thought: mediawiki.action.view.redirectToFragment.js does

if ( window.location.hash === fragment ) {
  window.location.hash = fragment;
}

i.e., it sets it to the value it already has. Maybe the Firefox people decided not to do anything if location.hash is set, but the value doesn't change?

Only stuff vaguely related in upstream I could find is https://bugzilla.mozilla.org/show_bug.cgi?id=483304 and https://bugzilla.mozilla.org/show_bug.cgi?id=668213

@Jhernandez (and @Jdlrobson), I tagged this Web-Team-Backlog in case the MediaWiki-User-Interface Backlog column isn't tracked closely (I think only the Skins column is tracked closely, as the MediaWiki-User-Interface Backlog column is extremely long).

Is this bug still relevant? Bug was raised in 2014.. is it still an issue in latest Firefox?
@dr0ptp4kt MediaWiki-Interface is tracked.

@Jdlrobson: yep. Just followed the first link in the description, using Firefox 42, not logged in.
Expected result

Thanks for confirming @He7d3r !

If I'm not mistaken the collapsing code lives in MediaWiki:Common.js ?
The code needs to be updated with something like this that runs after the collapse has occurred:

var hash = location.hash;
location.hash = '';
window.location.hash = hash;

If it were caused by the "classical" collapsible elements, then yes (and it could be fixed by fixing T71550, which depends on T32352).

However, the problem also happens with MediaWiki's jQuery.makeCollapsible plugin: https://test.wikipedia.org/wiki/Redirect_test_1

I am also observing this behavior in Chrome (on Ubuntu, ​
google-chrome-stable 50.0.2661.75-1)

Fixed by the change in T42792?