I noticed that when linked to through tables, redirects act very strange, at least for Firefox. Basically they don't go where they're supposed to...details below. I've gone through and fixed things for the Auras and Unique-Slot accessories, but I'm wondering if there's an easier solution for the bulk of accessories regarding template fixes (there's a special template used for the above kinds of accessories, and a general template used for the rest - you can see "templates used on this page" on the bottom of a page in Edit mode - wondering if we can have a quick fix for the general template).
The Lockbox page has the same issue as the Prize Box page regarding redirect links and certain browsers (see the discussion tab for these pages). It's just not as apparent on the Lockbox page because the list isn't very long - yet. I'm not sure if effort should be made to fix things for iron, as long as Iron is left at the top (as it should be if the list is DoR by default, which IMO it should be DoR by default)...but I mean, all things should be consistent. Harrumph. But for other boxes further down the list... What makes this annoying is that I don't know any nifty table/template tricks to force the column to differentiate between different acquisition methods - if these things were 100% certain to only ever come out of a box and nowhere else, then the coding used in the This Template would be a super easy solution. Alas, single-acquisition source is not the case for many accessories (like the Aura in general, or specific kinds like Volcanic Spike Mohawk). Additionally, some accessories come from non-box places (like the steam dragon wings), which requires links that can't simply be "plug 'n chugged" like other sources. So, it's tedious, but at least it can be fixed...with my time-consuming, not as-slick feeling method. Anyone know any better solutions? I'm not going to go through and fix ALL the accessory tables on each page right now, since it's not a huge issue on this page yet...but mostly because I don't want to do a ton of work in case there is a nifty trick (a simple template line of code that fixes all the pages at once, which is of course the point of a template) that can solve this for all browsers. I really don't want to have two different acquisition columns, but I think that's what I'll end up doing after a good long while if nobody can come up with something nifty for a single column.
TL;DR: links that lead through redirects in tables land users who use certain browsers (firefox, idk about others) on weird, seemingly random, incorrect spots on the redirected-to page . For whatever reason, the [[Page#SpecificSpotOnPage|SpecificSpotOnPage]] type of coding does not seem to have this problem. is there a quick template code solution that doesn't break tables or lose acquisition information for a single column? Or is there something that users need to do to firefox (or other browsers that might have this problem) to get it to treat the redirect coding correctly?
EDIT: it's not just in tables. Linking with [[Something that is redirected to a #specific spot]] through redirects, even if it's not stuck into any other template, just by itself...using it in an attempt to get on a specific spot on the page is really funky - tested it on the news page. And yes, the redirect page itself is correct, as are the ToC hidden header ==specific place== names... - it takes you to the right place when you click the #specificspot link on the redirect page itself.
This...is really weird...what's going on? I feel like I'm missing something fundamental...about my browser...or template coding...I wish...I could just KNOW...what to do...with template codes...all I know is a trick here and there, but I can't fully just DO what I want. So frustrating.
If this is all just a wad of jargon, I can upload a video or something showing what happens when I click through things. Would LOVE for this to be an issue that only I run into using my browser. Seriously not joking, I would prefer that - less work for us!
Sometimes it is browser caching with html redirects in general.
It is easily repeatable on pretty much all browsers by doing the following:
Visit a page with an html redirect (have the page end in #Something).
Scroll up/down on the page.
Refresh the page.
It can also occur if the page loaded attempts to visit the location of the scroll-redirect before the page is done loading (and changes size).
If it is either of these, then there is nothing we can edit to change it. [ok - we could standardize frame sizes - but I'm no where near willing to almost literally change every wiki page to define a frame size around all the text/images.]
If it is not one of these, then I'm not sure I understand the problem just yet (and need to reread the symptoms).