Page MenuHomePhabricator

Redirects to section are off in Firefox 29.0.1 if there are collapsed elements above the section
Closed, ResolvedPublic

Description

From https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=609193453#Redirect_not_working_right

As of FF 29.0.1, redirects to section links are off if the page contains collapsed elements before the section link. Was fine in FF 28.

Looks like a race condition between the collapsing code and mediawiki.action.view.redirectToFragment.js

Example link: https://en.wikipedia.org/wiki/Wikipedia:NMOTORSPORT

Should go to https://en.wikipedia.org/wiki/Wikipedia:Notability_%28sports%29#Motorsports

Second link works, first link doesn't; through the redrect-to-section, you end up below the "Motorsports" section. Offset from the intended destination appears to match the height of the collapsed FAQ box at the page top.

The issue is not limited to en-WP, same behavior also observed at the Commons. Try https://commons.wikimedia.org/wiki/COM:NETCOPYRIGHT
This should go to https://commons.wikimedia.org/wiki/Commons:Copyright_rules_by_subject_matter#Internet_images
but actually ends up too far down, again the offset appears to correspond to the combined heights of the two collapsed elements above that section.


Version: 1.24rc
Severity: normal

Details

Reference
bz65468

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:21 AM
bzimport set Reference to bz65468.
bzimport added a subscriber: Unknown Object (MLST).
Lupo created this task.May 19 2014, 5:58 AM

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.

Lupo added a comment.May 19 2014, 9:58 AM

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?

dr0ptp4kt set Security to None.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 12 2015, 7:40 PM

@Jhernandez (and @Jdlrobson), I tagged this Readers-Web-Backlog in case the MediaWiki-Interface Backlog column isn't tracked closely (I think only the Skins column is tracked closely, as the MediaWiki-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.

He7d3r added a comment.EditedDec 8 2015, 10:39 AM

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


Actual result:

Thanks for confirming @He7d3r !

Jdlrobson added a comment.EditedDec 15 2015, 12:27 AM

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?

TheDJ closed this task as Resolved.May 5 2018, 7:54 AM
TheDJ claimed this task.

This specifically was caused by a use of mw-collapsible indeed. Indeed fixed now. Until you have centralnotice at least ;)