Anchors doesn't work in chrome

[rockeet]

Any anchors does not work in chrome, but works in IE.
I checked the html source, it seems github add "user-content-" prefix for anchor name/id and set class="anchor" .

[gjtorikian]

Yes, we add the user-content- prefix to all of our IDs. But could you link to a file where the anchors are not working?

[rockeet]

In chrome, an url with an anchor don't scroll to the anchor's position in the page, such as:
https://github.com/rockeet/nark-bone#memmove-able

In IE, it is OK, the screen showing the page start at the anchor's position.

Chrome version: 19.0.1084.56 m
IE version: 11.0.9600.17420, with update version: 11.0.14(kb3003057)

[gjtorikian]

Chrome version: 19.0.1084.56 m

That's an extraordinarily old version. In the latest (39), it works fine:

I suggest you update, if it's possible. Our recommended browser version policy is here: https://help.github.com/articles/supported-browsers/

[mojavelinux]

I like the screencast. Very effective way to get the point across.

As I side note, when testing this myself, I did notice that the mobile website doesn't carry over the anchor position when you click "View README.md" from the home page. Perhaps something to think about supporting in the future.

[mojavelinux]

Actually, it doesn't seem to work at all in the mobile version.

[gjtorikian]

/cc @github/dotcom-mobile re: anchor breakage. Any thoughts here?

[jasonlong]

It looks like we're missing the JS on the mobile side that handles these #user-content-* anchors. Will get a fix out ASAP.

[gjtorikian]

❤️ @jasonlong

[mojavelinux]

\o/ Thanks @jasonlong!

[jasonlong]

Mobile anchors should be fixed up now.

[mojavelinux]

Solid! I'll let the twitterverse know.

[mislav]

There are still subtle bugs around our handling of anchors because of the fact we prefix everything with user-content-. One such bug is that when you click on a link that's supposed to take you to an anchor position, such as a link in a Table of Contents, the scrolling won't happen if that anchor is already in your URL, like #installation. The native browser behavior is that scrolling should always happen, regardless of the current anchor. We're discussing about how we can improve this handling.

[hail2u]

There seems to be another bug in user-content- prefixed id value.

When heading text contained non-ascii characters, id value should be escaped by URL encoding, but not. This breaks anchors working in Internet Explorer 11 and Chrome 39. Firefox 34 seems to be able to handle this type of id value.

[tony]

There seems to be another bug in user-content- prefixed id value.

Experiencing this now w/ anchors (internal targets) with reStructuredText:

On https://github.com/tony/django-pure/blob/b2046df5967f023/README.rst.

Clicking "startappdifferences" correctly links to https://github.com/tony/django-pure/blob/b2046df5967f02/README.rst#startappdifferences.

However, the internal link is as follows:

<p id="user-content-startappdifferences">Confusingly perhaps, django's default app created with <code>django-admin startproject</code>
is not the same output as an app with <code>django-admin startapp</code>.</p>

If the prefix is intended to be expected behavior, I could adjust https://github.com/github/markup/blob/master/lib/github/commands/rest2html to intercept and at the prefix. To do that we need a guideline of when user-content- prefixes are / aren't added.

[hwdsl2]

Someone please look at this issue. I tested yesterday that on mobile browsers such as Safari/Chrome on iOS, GitHub anchor links to the same page do NOT work. For example, use any mobile browser (e.g. on iOS) to visit https://github.com/jakiestfu/himawari.js and try to click on the table of contents in the README file. Nothing happens.

This is related to #716. Not sure why that bug was closed though.

[MikhailTymchukDX]

The page is not scrolled down to the last header when I open this link is Chrome: https://github.com/DevExpress/AjaxControlToolkit/wiki#reference
However, all previous header anchors works fine.

[HWL1223]

Hello; I am not a coder but am having an anchor problem I cant fix in Chrome Version 48.0.2564.116 m. The anchor does works in IE 11.
So my home page has this: <a id="start"></a>and it works fine ON the same page called like this: full url/index.html#start. (I have also tried other prefixes like div, name, etc.)
But using the same command, like in a menu, -> from another page<-, does not work in Chrome. It just goes home and not to the anchor. Nor does pasting the full url in work when not on the index page.
I have buried both my css files and my js file and that didnt fix the issue (meaning removed them to see if they interfered).
Ideas? Thanks.

[indexmod]

May be there is some way to off the anchor? My latest Chrome shows paragraph sign instead one. (Mopping up MDwiki engine hosted via Editey)

[ewcchan]

The bug here makes second click of the same anchor not working. and it failed on other browsers as I tried in FF, chrome and IE.

problem

When a user clicks on an anchor and jumps to a header, if user scrolls back to the top or somewhere else on the page and clicks on the same anchor browser does not jump to the header.

what I had found so far...

I found that to workaround the issue, I always have to prefer the anchor link with user-content-.
so instead of wiki markdown
[my header](#my-header)
I have to use
[my header](#user-content-my-header)

Could this be investigated and fixed?

[ewcchan]

I got feedback from github support that this is fixed in GHE 2.11.

[madelinemm]

Hi there. I was hoping I could get some help here with what seems to be a recent anchor issue on my site at http://www.m3creations.com/. The menu items NO longer link to the sections when using Chrome, but do work in IE, also work on mobile. Issue is isolated to Chrome but I can't figure out a fix.
This is a copy of my .js files:
cPanel File Manager v3.pdf

[marloes2294]

@madelinemm I have exactly the same problem, tried a lot of things and can't figure out what's wrong. In all the other browsers it works, except the desktop Chrome-version. If I manually add /#contact (for example) behind the URL, it also works. If you find a solution, please let me know.

[JoshBDunn]

I'm having the exact same problem as @madelinemm and @marloes2294. Will be checking back for updates. Thanks!

[madelinemm]

I have tried a few things to fix the issue but still not resolved. I have reached out to Chrome support. Unfortunately they don't even have a category for this issue.
https://support.google.com/chrome/answer/2898334?hl=en&ref_topic=7439644

[JoshM1514]

@madelinemm @jdwebskey Having a similar issue to you both, though I am definitely not experienced enough to play around with my site too much. I'll check back for updates too - do let me know if you manage to find a fix and I'll do likewise!

[sthibaul]

Hello,

This is also a concern when using firefox in caret navigation mode (F7):

• Go to https://github.com/themix-project/oomox
• Enable caret navigation with f7
• Go to "Arch Linux, Manjaro" link inside the README.md box, which is a link to internal anchor: <a href="#arch-linux">CentOS, Fedora, Mageia</a>
• Hit Enter
• Type right arrow

Actual results: Caret is still inside the "Arch Linux, Manjaro" link.

Expected results: Caret should have gone to the anchor.

The screen does scroll because of the javascript bits, but the browser's caret does not actually jump there. It would be enough to fix the generated README link code into

<a href="#user-content-arch-linux">CentOS, Fedora, Mageia</a>

which would also make them work without javascript support in the browser.

[sthibaul]

Since I don't seem to be able to reopen the issue, I have opened #1210