Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Ziusudra]

This screenshot from someone else on discord:

Spoiler (click to show/hide)

I see it happen on Chrome on Android, but not on Brave on Linux. I saw it on one other page a day or two ago, but can't remember which it was.

[lethosor]

There's not much I can go on here, unfortunately. It looks like the screenshot is of a pretty narrow window, which is known to cause some oddities with the top navigation tabs (even on Wikipedia), but I couldn't reproduce the issue seen in your screenshot.

If you do see this again, does the page also seem to take a very long time to load? We performed a server migration a week or two ago, and the new server setup has been a bit slow sometimes. I'm wondering if some CSS file simply timed out in this case (in most browsers, this would result in visible content, but a loading spinner in the address bar for a while longer - not sure how Chrome on Android represents it, though).

[Ziusudra]

DF2014:Baron is the other one. Happens on that but not v0.34:Baron.

Neither page takes long to load.

It also happens on the Samsung Internet browser, the LastPass browser (which both may be based on Chrome), and Firefox on Android tablet. Even when in landscape orientation. My tablet's resolution is 1920x1080. It must have something to do with some Android setting.

It doesn't happen on Brave or Firefox on Linux even when the window is as narrow as I can make it.

[Ziusudra]

Ah, new info, it happens on Brave and Firefox on Linux if I am NOT logged into the wiki.

And it does NOT happen if I type "baron" into the search box and just hit enter. It then happens again when I reload the Baron page. So something about the redirect. (Typing "Toady One" or "Toady_One" does NOT keep it from happening. The space gets replaced by a "+" and with the "_" it's not a redirect or not the same kind.)

Edit: and it does not happen on android if I'm logged into wiki. So, being logged in prevents it. Then after logging out it happens again.

[Starver]

I checked. Android, currently, and both Firefox (set to "Request desktop page", though I don't think that matters here) and Chrome browsers show https://dwarffortresswiki.org/index.php/Toady_One more or less as shown.

Search for Baron (only tested on FF) gives https://dwarffortresswiki.org/index.php/DF2014:Baron as it should with "miner" artwork and side menu area (including ad) off to the side in both landscape (as I default to holding for browsing), and rotated to portrait. Ads above title and below categories Ok.

Click on v0.34 for https://dwarffortresswiki.org/index.php/v0.34:Baron and it looks just as sane.

Then either click on v0.47.04 or back-a-page to https://dwarffortresswiki.org/index.php/DF2014:Baron and it displays wrongly. As it does if I paste https://dwarffortresswiki.org/index.php/DF2014:Baron into the address.

Editing or pasting https://dwarffortresswiki.org/index.php/Baron as the address gives it loading right, even though it changes the address to the Namespace: version, and a Refresh of the page makes it wrong again.

'Wrong' here is the side-stuff (normally to the left of the lined white box, in the grey 'bakground') now sitting a very similar place within the box as it should be within the whole page, overcompositing the white-box contents. Similarly, the top-ad that should sit between the 'tabs' (of "DF2014" "Discussion" "Rate", gap, "Read" "Edit", "View History" and search-widget) and the "2014:Baron" title now sits behind the tabs, the Title itself is shifted over the "xTATTEREDx" quality item in that list.

The ad below the Categories seems Ok, but may just have nothing to be interfered with.

Spoiler: The next bit goes all rambling, but(/and) is my inexpert diagnostic (click to show/hide)

Without digging into the source/css (slightly awkward to do, here in an Android browser, at least in trying to cross-compare) my best guess is that the DF2014 namespace templating (which does not get called when redirected to in leiu of namespace, even though it defaults to DF2014 content and post-processing) somehow has the sidebar elements positioning relative to the 'internal' page element (the "white box") not the browser page (or a more senior element that is the "grey background").

This sidebar grouping clearly has a greater precedence (more towards the viewer) than the white-box, and includes the Tabs and Title. The row of tabs has no lower border for the active tabs (by default the namespace, read and search-widget element that cleverly aligns over the upper border of the "white page" normally (exactly that one pixel of border) but the misaligned version (one full sidebar to the right and the verticality of the top-margin downwards) reveals the white-box top border as continuous.  It's hard to decipher, but it looks like the Quality bar is tied to the verticality of the Title (but aligned to RHS, so gets closed in on?) while being a lower-precedence. The base font-size is a point or three smaller, also, meaning the text below the title (which is also subject to a that relative point difference, though bigger-as-a-title than its body-text, doubtless therefore a cascaded inheritance issue from being in the 'wrong' bit of a tree rather than absolutism) has more characters per line and already by the first line does not match vertical position to sidebar items the non-wrong does. (Just noting this, to support my theory, other than the overlay issue I have no problem with that more text per line.)


At a guess, the page renders the grey background, the white box the, the ads in the white box, (the bottom one relative to the bottom, wherever the subsequent padding needs to put it) and the maintext (including infobox) and I'm not sure about the Quality line (and the probable <HR> beneath it) but maybe that's done as the initial maintext with some padding above it. Then the sidebar is applied, should be related to a higher level, but is anchored to the whitebox instead. It has two elements: the actual sidebar (miner image, which has the <HR> now sliced below its lower extremity, actual side-menu and then the side-ad) and the floating Title that is given the right padding to appear on the same height as the Quality bar, but inherits the wrong relative position to float too far over from its rightful position aligned to he LHS of the <HR>.

And this only seems to happen under (not redirected-to) implementations of the DF2014. So I'd look somewhere in the start of the sidebar-context of the given templates for a change, though I'm not familiar enough with the default redirection mechansm in Wiki use to understand why that makes a difference. Nor why there should be a Namespace: difference, though as the "This is about..." box colours different for non-DF2014 pages than the DF2014 one (redirected-to or not!) there is at least one thing that relies on this, however much this drills down from the original page-request.

[lethosor]

Then either click on v0.47.04 or back-a-page to https://dwarffortresswiki.org/index.php/DF2014:Baron and it displays wrongly. As it does if I paste https://dwarffortresswiki.org/index.php/DF2014:Baron into the address.

Interesting! I was able to reproduce this on both desktop and mobile when logged out (but not when logged in). Not sure what's going on here, but at least it's consistent, although troubleshooting it could be tricky.

Without digging into the source/css (slightly awkward to do, here in an Android browser, at least in trying to cross-compare) my best guess is that the DF2014 namespace templating (which does not get called when redirected to in leiu of namespace, even though it defaults to DF2014 content and post-processing) somehow has the sidebar elements positioning relative to the 'internal' page element (the "white box") not the browser page (or a more senior element that is the "grey background").

There's nothing special about CSS in different namespaces - the namespaces are essentially just part of the page title. Yes, the article version box changes color on different pages, but that's just the template looking at the page title and adjusting itself.  You can take a look at the site-wide CSS here:
https://dwarffortresswiki.org/index.php/MediaWiki:Common.css
https://dwarffortresswiki.org/index.php/MediaWiki:Vector.css

There also shouldn't be a difference between the redirected and non-redirected pages. An interesting feature of Mediawiki's redirects, though, is that they don't actually issue HTTP redirects - fetching https://dwarffortresswiki.org/index.php/Baron will return the contents of DF2014:Baron, and then some JS updates the page title on the client side (so if you disable JavaScript on the wiki, the URL will remain https://dwarffortresswiki.org/index.php/Baron). I'm guessing that some broken render of the page is cached under one of these URLs but not the other. Not sure why it would have broken, though. I'll double-check with other admins and see if they have ideas.

[lethosor]

Ok, turns out there was some broken HTML that was only live temporarily, but must have made its way into the cache of some rendered pages. Also, redirected pages (like "Baron") don't seem to use the cache for some reason, so that was probably why it was displaying as expected. I've cleared the cache, so any pages you visit now should be fixed. Let me know if you spot any others that are still broken.

[Starver]

For my part, it looks fixed.  I used the Random Page link to go a-visiting, clicking across to the DF2014 link when I landed off of it[1], refreshing it if I landed on already (though it never was a "redirected" page, being a smarter Random-lander than that). No obvious signs of it persisting on anything I went to, so probably a good enough little sample to pronounce it solved. For me, but probably for others.

Cached problems (that don't affect login, I suppose because logged-inedness forces a version upon you to say "Logged in as <foo>"[3]) are of course a pain to work out. Not quite Heisenbug territory, but a related variation.


Though I seemed to omit it, in that last lot of scrawl, I had tested and found the Talk pages for the affected pages (Toady and Baron) were clean/unfaulty, now explainable by the cache issue (they were not visited and cached-faulty when the fault existed to be cached, even if at least the DF2014:Baron and Toady One main-pages were), and so this time I think I went into a decent proportion of the checked-good pages to ensure they didn't then have faulty-Talks 'behind' them, as a reversal of fortunes. None did! Not that I expected them to have, but as I didn't mention the prior discovery, I thought I better do that double-check myself just now.


Anyway, glad it's sorted. Or an easy answer is found for any page not yet discovered needing 'healing'.


[1] And though the first few times gave me exclusively v0.34, making me think Random was somehow limiting itself to them, it did start to give me other-namespace pages (eventually including the 'current' set) and no-namespace ones ("Where should I build my fort?", version independent). Plus, ironically, the namespaced-but-non-'switching'[2] https://dwarffortresswiki.org/index.php/DF2014:Release_information/0.42.06

[2] Yes, I fully understand that there's no reason to switch to a v0.34 version of a page specifically describing 0.42.06. I'd have only worried if it looked like I could!

[3] Either does not cache/always builds anew or else has a possible cache only of the last version you with your login fetched, when it was clearly not broken to cache-as-broke, because you'd have seen it broken and done what you need to to solve it already...

[Ziusudra]

Yep, fixed here, too. Thanks.

[lethosor]

Cached problems (that don't affect login, I suppose because logged-inedness forces a version upon you to say "Logged in as <foo>"[3]) are of course a pain to work out. Not quite Heisenbug territory, but a related variation.

Yeah, that's at least part of the reason. It might be possible to cache just the page contents (i.e. the rendered version of the wikitext source code of each page), but most of our traffic is logged-out users anyway, so there's not much point. Logged-in users also tend to be the ones changing templates, so it's convenient for pages' caches to auto-clear when they're visited.

[2] Yes, I fully understand that there's no reason to switch to a v0.34 version of a page specifically describing 0.42.06. I'd have only worried if it looked like I could!

{{av}} (the template you're referring to) is generally included only on top-level pages, e.g. "DF2014:Release notes" but not "DF2014:Release notes/0.40.01". In the case of release notes, yeah, it makes sense.