Last modified: 2011-02-20 17:25:33 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 27468 - Force underlined links don't work in 1.17 monobook
Force underlined links don't work in 1.17 monobook
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
1.17.x
All All
: Normal normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 26676
  Show dependency treegraph
 
Reported: 2011-02-16 20:12 UTC by Derk-Jan Hartman
Modified: 2011-02-20 17:25 UTC (History)
3 users (show)

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


Attachments
Path to order userprefs correctly (1.86 KB, patch)
2011-02-20 16:34 UTC, Derk-Jan Hartman
Details

Description Derk-Jan Hartman 2011-02-16 20:12:01 UTC
This probably works on trunk, but is broken on 1.17
Comment 1 Mark A. Hershberger 2011-02-17 00:02:05 UTC
Why do you say "probably"?  Have you tested it anywhere?
Comment 2 Phlip 2011-02-17 09:34:13 UTC
The problem appears to be the a{} block in skins/monobook/main.css?301-1 on line 65 (at least, that's where it is on the file currently on en.wikipedia). The text-decoration:none; line there is overriding the a{text-decoration:underline;} in the HTML (as they're the same specificity and the stylesheet is imported after that decoration in the HTML).

Browsing SVN, the generation of that a{text-decoration:underline;} bit in the HTML seems to have changed in trunk (moved from Skin.php to ResourceLoaderUserOptionsModule.php) but it appears to still work in the same way. And that block in skins/monobook/main.css isn't changed. So I suspect it would still be broken in trunk, though I don't have a working trunk site to test it on.
Comment 3 Derk-Jan Hartman 2011-02-18 10:36:44 UTC
Right ... @Roan, remember how I at one point stated that we did not need ALL skins converted to ResourceLoader in 1.17 ? I was mistaken, we need it for this issue.
Comment 4 Derk-Jan Hartman 2011-02-20 16:34:25 UTC
Created attachment 8182 [details]
Path to order userprefs correctly

OK, patch attached that will fix this. However, first some comments.

1: The order of loading these items is actually affixed in buildCssLinks() of OutputPage.php
It was
other (static stuff, and all private modules, including user preferences css)
dynamiclinks (here is where the old style skins and other unported material will be)
site
user

2: The type of the ResourceLoaderUserOptionsModule is private, not user and buildcsslinks puts private modules with the 'other' modules.

I considered changing this simply to user, in the hope that that would fix it, but I don't know what kind of consequences that has for caching etc. Also since this order is actually rather specific, I went with the approach in my path.

I created an improved order in buildCssLinks that manually makes sure that the css from the preferences is between the site css and the user css (as it has always been). I'm also using a for loop, though we could of course continue to use array_merge, in my experience though, it ordered 1 2 3 as 132 for some strange reason, so i went with the foreach approach instead.
Comment 5 Roan Kattouw 2011-02-20 17:25:33 UTC
Fixed in r82518.

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


Navigation
Links