Last modified: 2011-04-13 20:17:51 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T25902, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 23902 - Special:Search NS selection Javascript broken
Special:Search NS selection Javascript broken
Status: RESOLVED WORKSFORME
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
unspecified
All All
: Normal major (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-11 09:04 UTC by Church of emacs
Modified: 2011-04-13 20:17 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Scenario: User clicks on "Hilfe und Projektseiten". The first time it doesn't work, the 2nd time it does (265.02 KB, image/png)
2010-06-11 09:04 UTC, Church of emacs
Details
workaround in CSS (355 bytes, patch)
2010-07-07 01:44 UTC, entlinkt
Details

Description Church of emacs 2010-06-11 09:04:53 UTC
Created attachment 7459 [details]
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.
Comment 1 Guandalug 2010-06-11 18:56:48 UTC
Bug was CSS-based, and deWP-specific. Fixed by repairing the CSS 'overrides'. 

http://de.wikipedia.org/w/index.php?title=MediaWiki%3ACommon.css&action=historysubmit&diff=75462968&oldid=75430138
Comment 2 entlinkt 2010-07-07 01:41:32 UTC
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.
Comment 3 entlinkt 2010-07-07 01:44:26 UTC
Created attachment 7556 [details]
workaround in CSS
Comment 4 entlinkt 2010-07-07 02:04:39 UTC
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.
Comment 5 DieBuche 2011-04-13 20:17:51 UTC
Can't reproduce anymore

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links