-
Well we know why it happens; browsers chose to interpret a vague paragraph of an old RFC in a way that meant that they abandoned the #anchor during redirects.
On other sites, my browser is happy to be redirected from, e.g.
randomforum.com/showthread.php?goto=newpost&t=97074 to randomforum.com/showthread.php?p=2994810#post2994810
or
timetriallingforum.co.uk/index.php?showtopic=92586&view=getnewpost to timetriallingforum.co.uk/index.php?showtopic=92586&pid=1284720&st=30&#entry1284720
the #anchor in the query string of the redirect url doesn't get lost, and the browser jumps to the #anchor when I get there. In the olden days, Opera used to have a problem jumping to an #anchor because it jumped there and then rendered all the images and the anchor point rapidly disappeared off the bottom of the screen, but New Lfgss is the first instance I've ever seen of the #anchor not appearing at all.
gbj_tester-
That's not a "redirect" in the sense that velocio is talking about - that's just a straight link to another page on a website with no redirection going on. The redirects that are affected with the dropping-anchors problem are true redirects, those that involve a 3xx HTTP status code. The redirect happens on the server, in the background, after you've requested the original resource. So that's why it's handled differently on timetriallingforum.
(I don't know why NLFGSS uses 3xx redirects in this way but there's presumably a purposeful architectural reason for that)
bothwell
Well we know why it happens; browsers chose to interpret a vague paragraph of an old RFC in a way that meant that they abandoned the #anchor during redirects. There was even a draft RFC to explicitly say "keep the #fragment", but it seems that Safari and some other browsers (some Opera, some older IE) haven't done this.
Chrome did implement it correctly, and latter versions of Firefox did too.
We do think we have a solution, but wiring it up is going to take a little time and will have a broader impact than most of these fixes. So it's going to require a lot more testing and for us to have access to more devices that suffer from the issue.
The solution is to detect whether we are going to ask you to redirect, and to copy the #fragment value into the querystring before hand. Then, in the web page we'd use JavaScript to read the querystring and fragment... if it had both, we'd do nothing... but if it had a fragment= querystring without the #fragment bit, then we'd tell your browser to jump to the right part of the page.
Therein lies another problem with this... jumping to part of a page may not be consistently support (using jQuery), and if we chose to stick the #fragment back on the URL and reload the page it will cause additional page loads and fill your browser history with noise.
Hence... it will be tested before it gets rolled out, and as we'd need to modify all redirects that could have fragments it will take time to do.
It would've been great if this had come up in testing. Months of urging people to do so, but only a small subset of people did. Of those, most were using Chrome and Firefox (which together make up something like 70% of all traffic to LFGSS... IE is less than 6% in total, Opera doesn't register (fewer than 100 people out of hundreds of thousands of visitors per month), the big gap is made up by Safari on various platforms and the Android browsers... and 1 person uses a Blackberry).