Page MenuHomePhabricator

Special:Search NS selection Javascript broken
Closed, DeclinedPublic

Description

Scenario: User clicks on "Hilfe und Projektseiten". The first time it doesn't work, the 2nd time it does

Hi,

it's difficult to describe this error, see the screenshot attached.

Steps to reproduce:

  1. Go to http://de.wikipedia.org/wiki/Special:Search (oddly, it only seems to happen on dewiki)
  2. Click on either of the links "Multimedia", "Hilfe und Projektseiten", etc.
  3. The correct page isn't loaded, instead the link gets displaced
  4. Click on it again and it works.

That doesn't always happen, so you might need some tries until you see the error.
I confirmed this bug in Firefox 3.6.3 and Chrome 5.0.375.70 beta.


Version: unspecified
Severity: major

Attached:

SpecialSearch-JS-Bug.png (1×723 px, 265 KB)

Details

Reference
bz23902

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:01 PM
bzimport set Reference to bz23902.
bzimport added a subscriber: Unknown Object (MLST).

I'm sorry to say that Guandalug is not entirely right. The bug was indeed made worse by stuff in [[de:MediaWiki:Common.css]] (in that it became visible even without https), but is present on any wiki that is on a https server.

What's going on is really weird. The links inside the buttons initially have href attributes with a relative URL (e.g. href="/wikipedia/de/w/index.php?title=Spezial:Suche&fulltext=Suche&ns0=1&redirs=0"). When they are clicked, they become absolute (e.g. href="https://secure.wikimedia.org/wikipedia/de/w/index.php?title=Spezial:Suche&fulltext=Suche&ns0=1&redirs=0&search="). And now the skins try to add neat icons next to them and mess around with the padding, because the href attributes suddenly match rules like (from vector):

#content a[href ^="https://"],
.link-https {
background: url(images/lock-icon.png?2) center right no-repeat;
padding: 0 13px 0 0;
}

The easy CSS fix is to not let them do this (I'll implement this in [[de:MediaWiki:Common.css]] and attach a patch). But I wonder why the URLs have to become absolute at all.

Created attachment 7556
workaround in CSS

Attached:

Another (and probably better) approach is to let the skins add their icons only if the class "external" is present (which it is not in this case). All the skins would have to be checked, however.