Yeah, both TF2B and OPTF2 use the same WebAPIs which have been rather neglected by Valve - part of the reason why TF2B has sat idle over the last year. If backpack.tf isn't effected it's probably scraping the inventory JSON or something.

Can't really fix the issue as there is likely no way to distinguish an legit item from slot 3 with a bugged one.

All I can really say is if you'd like to see things improve in this regard, contact Valve and make a case for the value of having proper consistant APIs.

And the item in question is definitely not assigned to the 3rd slot?

With the way items in such a state are handled by TF2B such a bug shouldn't be possible, I'll take a look either way but this sounds more like API/Item system oddity at first glance.

I've reproduced the issue in Firefox at extreme negative-zoom levels (Amusingly IE11 works perfectly), but I'm not exactly yet sure how to appropriately fix the issue.

I'll be rolling this in alongside the mobile and nano reworks. Hopefully should be soon.

Investigating.

It's been temporarily removed as it was rather broken.

It'll return soon hopefully as I clean up the myriad bad design decisions (UI and Backend equally) that've accumulated over the years, and take another stab at making the UI work nicely on mobile devices. (As that was the general idea of Nano in the first place)

This happens when you have items in your backpack either with strange item names or gifted from people with strange names.

By "strange" I mean various non-latin unicode characters. Remove the names and the output can be parsed.

Known issue that should now be fixed.

I'll hold my hands up and admit that I was lazy and left it in after banging my head against another rather annoying bug last night.

Problem should now be fixed.

I'm fairly certain I know what the root cause of this is, but I'll have to poke around first.

I'll get back to you when I have a fix.

I'll need to take a look into how it's implemented, but I make no promises.