Wedge

The reason the bug didn't show up in mini-menus before I added the thought menus, is because there never was any overlap between these menus.

I made a quick test to remove most elements in the page, and sure enough, in a topic page, the user name shows up on top of the currently opened mini-menu (from the previous post.)

And believe it or not, I actually managed to fix it, ahem...
Not in a usable way.

I just replaced the ul's top: 100% declaration to bottom: 100%... As a result, it goes UP, but it also shows correctly.
I said it -- not usable. But still...!! The problem is, thus, not only in having a "position: relative" element outside of the current 'position' stack, the problem shows up only when setting a 'top' value on the absolutely positioned element Inside the stack.
Not setting top or bottom at all also fixes it... Which is why, I guess, we never had the problem in the main menu: this is because I didn't use positioning this way.

So, basically, I've reset the main menu code pretty close to what it used to be (and forfeited at least 100 saved bytes in the process... -_-), I'll try to make a IE6/7-specific version later, so as not to 'encumber' non-oldIE browsers with legacy code.
Still, I'm very, very upset. I still can't find any web page mentioning that at all. IE bugs are so thoroughly documented, I went through hasLayout and positioniseverything, two of the best sites for these, none of them mention this bug... -_-

I'm so tempted to drop support for IE < 8.. :^^;:
This isn't like me.

Is it related to the word 'localhost' itself..? Maybe?
I'd recommend adding a shortcut to unwedge.com or whatever in your hosts file, and accessing your local site from that... I've never had PURLs problems with that setup.
Of course, YMMV.

Okay, here's an example of what I'm seeing with IE10 in IE7 compatibility mode... That's awful.
This is supposed to be a mini-menu in the thoughts area.

What's happening then?
Here's the simplified structure of a mini-menu top-level entry:

<span>
   menu caption
   <ul>
    <li>contents...
   </ul>
</span>

'span' is set to position: relative
'ul' is set to position: absolute, so that for instance, setting top: 100% on it will position it right below the span text itself.

This works perfectly in all browsers, including IE8+.

In IE 6/7, and you can test on wedge.org if you'd like, the mini-menu is shown BEHIND the menu captions ("Action") for all other mini-menus. Not only that, but if you hover it, the mini-menu will close because it gives priority to the Action button that's supposed to be hidden behind it.

What's the reason for this..? Well, the span's position: relative is the culprit. If you remove it, then the mini-menu will never be overwritten, it will retain priority.
Only problem is, if I wanted to get rid of position: relative, I'll have to manually set (via JavaScript) the position for my mini-menu. Honestly, I'd rather not do that...!

Now, here's the thing: I spent the better part of the day LOOKING for examples of this IE bug online, but so far, I've found NOT EVEN a single description of the problem. It sounds as if the problem is ONLY on wedge.org, and/or ONLY on my PC.
Considering my IE6 copy is running in VirtualPC XP Mode, I can safely say it's the "real thing", and it's not a quirk of browser emulation, like broken filters in IETester + IE6.

I discovered the bug when I was trying to 'make things work' in IE 6/7 with regards to my main menu rewrite. I ended up giving up and reverting much of my changes, because I couldn't afford to drop compatibility with both IE 6/7 when it comes to the main menu.

I doubt anyone will be able to help, but it doesn't cost anything to ask. Can anyone reproduce this bug? And if yes, do you have any frigging idea what's happening..? Thanks!

So... Reproduced with this file list:

index.french (default, cached), plugin.french (Dragooon:WeMentions), Notifications.french (default, cached), index.english (default, cached), index.french (default, cached), Post.french (default, cached), ActiveMembers.french (live627:active_members), lang/TopicSolved-Display.french (Arantor:TopicSolved), SkinSelector.french (Wedgeward:SkinSelector), Stats.french (default, cached).

I've cleaned up the error log, its last entry is for that particular page load (17:38 for me, probably says 16:38 for you). I THINK. I can't say 100%, but I immediately stopped loading that page after I reproduced the problem, and went to the admin menu, while I was also disabling the logging of language file loading.
Only thing that surprises me is that it has like, 6 entries only for the page... Oh wait, it's probably right -- it can load multiple files per call.

Note that file lines are related to the current online rev, i.e. 2051, not the latest ones.
Also, I don't really see the point in making language loading a feature in the debug area... A better feature, would be to prevent logging some stuff like the block list, which is nice when you're reading a topic page and don't want to have this huge block list come up at the end, eheh... The magic of mini-skeletons ;)

So, interestingly... This looks like the problem is AGAIN due to getRePrefix...
I should have considered it, ah ah...

It simply wasn't "updated" for your new cache system, I guess..?
The reason this was broken, is that, hmm... It looks like I never committed that; AND I lost my changes. I don't know what happened, at all.
Anyway, it's an easy fix, so I'm redoing it...

Bummer. Hoping this didn't happen more than once, otherwise...

So, apparently you forgot to do it... :whistle:
Your CSS adds over 140 bytes (ouch).
Adding the 'final' keywords saved a total of 54 bytes.
That is -- nearly half of it.
As I said: please use final keywords when you're playing with anything that's used as an extend anywhere else...

Also, you forgot to add commas after your new .warn_* classes. I'm surprised you didn't catch it at commit time..?
Fixed locally.

So I guess it's with Dolphin on Android..?

This is the kind of thing you could specify, right..? And most importantly, your phone model, etc...

Anyway. I managed to reproduce this... But it ONLY happens when logged in. I tried logging in and out and checking the skin, I got Wireless by default for both, so it's a Dolphin bug... Not gonna fix that, until someone can reproduce on another configuration.

Reproduced in French, too...
Same files loaded, really. Same logic.

Adding debug_backtrace to loadLanguage is exactly how I fixed it the last time, so I'll do that here again, and give it a few minutes... ;)

Manuals are for noobs..? :P