[Yarn]

As the title says, the sidebar appears at the bottom of the page instead of the top when I view the wiki in Firefox 9. This does not happen in Internet Explorer 9. I have not tested it with other browsers.

Also, visited links in the wiki have the same color as the regular text, making it impossible to tell them apart. I suggest changing the color of visited links so they're distinguished from normal text.

[FreeSpaceFreak]

I have the sidebar issue as well, since upgrading to FF9. Not sure if it's a bug in FF or something that needs to be fixed Wiki-side.

And yeah, the visited links being indiscernible are a minor annoyance as well, that's been around for a long time.

[yuezhi]

As the title says, the sidebar appears at the bottom of the page instead of the top when I view the wiki in Firefox 9. This does not happen in Internet Explorer 9. I have not tested it with other browsers.

you're not the only one. 

Also, visited links in the wiki have the same color as the regular text, making it impossible to tell them apart. I suggest changing the color of visited links so they're distinguished from normal text.

is there any way to change this?

[rev_posix]

This is apparently a bug in Firefox (https://bugzilla.wikimedia.org/show_bug.cgi?id=31807).

There is a workaround on the mediawiki side, but it requires modifying a file on the backend and potentially breaking it for other browsers (potentially Konqueror).

Best workaround I've found is to use Adblock (or something that can block elements on a web page) to block */monobook/KHTMLFixes.css.

[Yarn]

Best workaround I've found is to use Adblock (or something that can block elements on a web page) to block */monobook/KHTMLFixes.css.

That worked, but only after changing the filter to /KHTMLFixes.css.

I still believe the visited-link color should be something other than white. Yellow, maybe?

[niffiwan]

Doesn't the bug report say that upgrading mediawiki to version 1.16 (or greater?) will fix the issue - and that it was caused by some dodgey browser detection being done by mediawiki?  We're running 1.15.5.  Latest is 1.18.1 

[rev_posix]

Doesn't the bug report say that upgrading mediawiki to version 1.16 (or greater?) will fix the issue - and that it was caused by some dodgey browser detection being done by mediawiki?  We're running 1.15.5.  Latest is 1.18.1 

It does.  However, manually upgrading isn't a simple case of drop it in and go.  As things are now, if there are security patches and such, they are backported to the current package install. Doing a manual upgrade would entail a bit of work and then it would be one more thing to have to keep an eye on and maintain.

A backport repo might be around somewhere, but then we would have to be dependent on another group/party to maintain that package.  It's a nasty circle, it is.

[niffiwan]

ah yes, the curse of linux package management, I'm very familiar with this particular conundrum   At work when in this situation we tend to build our own RPMs from source (with a borrowed spec file), but you don't want to have to do that for a lot of packages, and even less so when it's your own time!