Ref12 never navigates to the in-page anchors (Win 10, Chrome 49)
Closed this issue · 4 comments
[EDIT: I did find item https://github.com//issues/7 from 2014 which talks about the same behaviour but I have disabled AdBlock, per the suggestion there, and still experience the same behaviour.]
------ Original post ------
I'm currently in Windows 10 using Chrome (latest) 49.
Microsoft Windows [Version 10.0.10586]
Version 49.0.2623.75 beta-m (64-bit)
Google Chrome is up to date.
I have Ref12 4.2.1, installed 2015-10-27, and I have this extension set to Automatically update.
I've glanced over the list of 4 Open and 19 Closed issues and don't see anything like this.
For some months now I've been finding that Ref12 no longer (for me) navigates to the in-page anchors. It only ever drops me at the top of the reference source page (which can sometimes be hundreds or thousands of lines long.)
So, for example, in an ASP.NET UserControl of mine if I F12 on 'this.Session' I expect to be taken to the declaration of the Session property within UserControl.cs. It does take me to UserControl.cs (this alone is such a beautiful thing), however, it doesn't leave me at the in-page anchor for the Session property declaration. The URL that is first launched is:
http://referencesource.microsoft.com/System.Web/a.html#d45c76a5f73670ef
And when that's done redirecting the URL at which I'm deposited is:
With a bit of fiddling with that last URL I can see that if I take everything after the hashtag and change the comma to a hashtag, I get the right anchored URL and it takes me to the declaration I was expecting.
http://referencesource.microsoft.com/System.Web/UI/UserControl.cs.html#d45c76a5f73670ef
It seems possible (or even likely) this is an issue with http://referencesource.microsoft.com, and not with Ref12. Is it possible for Ref12 to navigate to the correct URL to start with?
Many thanks. Even in its current top-of-page-only form Ref12 is much more useful than [From metadata].
If you correctly end up at http://referencesource.microsoft.com/System.Web/a.html#d45c76a5f73670ef, this can't be a problem with Ref12.
Opening that link works for me; it redirects to http://referencesource.microsoft.com/#System.Web/UI/UserControl.cs,d45c76a5f73670ef (notice the lack of second hostname).
I suspect you have a proxy which is rewriting the Javascript and causing the SourceBrowser JS to include the hostname in the path.
I don't have a proxy, or at least not one that I'm running in this case. However, as you said:
If you correctly end up at http://referencesource.microsoft.com/System.Web/a.html#d45c76a5f73670ef, this can't be a problem with Ref12.
I think you're right. It's frustrating for sure.
Just to clarify, I don't end at the "a.html#md5hash" URL, but the navigation starts and redirects from there, leaving me at:
I'm going to Close this item because I've just done some more testing with that first URL, and it does all its machinations correctly in Edge, and in Firefox (which is running over a proxy). This is a Chrome-specific issue, but it's not a problem with Ref12.
Yes; that URL is redirecting you incorrectly.
Check your Chrome extensions, and try in an incognito window.
Suspect found and neutralized. You mentioned a proxy might be rewriting JavaScript and that got me thinking browser extensions. I disabled/reenabled my Chrome extensions one by one and found this one causing my problem:
Google Analytics Opt-out Add-on (by Google)
As soon as I disabled it the "a.html#md5hash" links being invoked (correctly) by Ref12 began (correctly) redirecting to the in-page anchors.
I appreciate the hint, and apologize for taking your time. I'll leave this here in case someone else comes in here with this problem.