I get the same issue in Linux Mint with Firefox 24.0 and Chromium 33.0.1750.152 with the French documentation (like you said) as well as the English documentation so it appears to be a generic cross-platform website problem.

For f***'s sake, this was "assigned" 3 years ago and is still not fixed!

... do you think I get paid for this or sighing?

Ha, wrote that last comment on mobile; meant to say "or something?"

> do you think I get paid for this or something?

Given the way you ask, I guess not, and I don't care. If you are not going to fix it, it should be assigned to someone else.

> If you are not going to fix it, it should be assigned to someone else.

Who? 

By the way this issue has been fixed and then broken numerous times. There is a JavaScript solution in-place and it works for me in Chrome on Windows - what browser are you using? Or are you disabling/blocking JavaScript?

> There is a JavaScript solution in-place and it works for me in Chrome on Windows

When you say it works for you, are you testing by going directly to a deep-link url like http://www.php.net/manual/fr/class.domdocument.php#domdocument.props.actualencoding (that does NOT reproduce the issue), or are you following the original report instructions, which are:
1 - first go to a page without the #segment part, e.g. 
http://be2.php.net/manual/fr/class.domdocument.php
2 - then click on a link that points to a #something anchor within the same page, e.g. the link to "$actualEncoding"?

Note that, in order to properly test for the issue, you need to make sure that the link is actually internal to the same page, with only the #segment part being different (I notice that sometimes, depending on language and stuff, the links might actually point to a copy of the same page on a different domain).


> what browser are you using? 

Chrome on Linux

> Or are you disabling/blocking JavaScript?

LOL no, of course not. (btw if this has to be handled by javascript one should seriously question whether something is very badly designed at a deeper level - not saying that I'd expect any webpage to work with javascript disabled these days, but it just shouldn't be necessary to use javascript for this kind of things. Anyway that's another story).

This seems to be the code that is supposed to do the job:

////////////////////////////////
document.body.addEventListener("click", function (e) {
    if (e.target && e.target.nodeName === "A") {
        var href = e.target.getAttribute("href");
        if (href && href[0] === "#") {
            var id = href.slice(1);
            var target = document.getElementById(id);
            // temporarily remove the id="" attribute so that the UA's
            // default scrolling is prevented
            target.id = "";
            if (target) {
                PHP_NET.scrollElementIntoView(target, null, function () {
                    // restore the id="" attribute
                    target.id = id;
                });
            }
        }
    }
});
////////////////////////////////

This would work if the links were like <a href="#something">, but instead, they are like <a href="relative.path.of.current.page#something">

so, the javascript code does nothing at all in this case.

Your attitude is unnecessary. Yes, we have problems, and yes, we've had them for a long time. Open a pull request that fixes it without breaking other things or just leave it alone and someone else, eventually, will fix it.

You are right; I was going directly to the link. However, I am still confident that it has worked and been broken in the past; the solution is probably not far off from what's there.

@teo8976, please read <https://bugs.php.net/how-to-report.php>.
Thanks!

For what it is worth, the most simple solution regarding jumping
to anchors on pages with a fixed menu at the top of the page, is
to set an appropriate margin-bottom for the *html* element.
However, that does not work well for jQuery[1] (I've never
mentioned any issue regarding vanilla JS, though).

[1] <https://github.com/jquery/jquery/issues/3676>

> @teo8976, please read <https://bugs.php.net/how-to-report.php>.

Is there any part in particular that I should pay special attention to?

I'm not sure why you point me to a guide on how to report bugs, I didn't report this bug.

> However, I am still confident that it has worked and been broken in the past

It's possible that:
A) you are right, it's been alternatively fixed and broken in the past, and that may be due to the fact that links from one part to another within a given page used to contain only the "#segment" (e.g. href="#something", like they should be) and then they have been changed to contain the full or partial relative url of the page (e.g. href="this.page#something", which would break the current js code, or href="http://different.domain/same.page#something", which would unnecessarily reload the page but work as expected, preventing the bug from being observed)
B) OR you are wrong, it hasn't been fixed and broken, it just can be observed intermittently, because sometimes the links contain a full URL that is different from the one of the current page (like it links to a different mirror domain), in which case the page fully reloads and the other part of the javascript code, which executes at page load time, always work.

Either way, my previous comment [2018-04-28 18:14 UTC] points out the exact cause of the bug and exactly what needs to be done to fix it permanently.

> Is there any part in particular that I should pay special
> attention to?

Yes, the third paragraph:

| […] The people who are going to help you with a bug you report
| are volunteers. Not only are you not paying them to help you, but
| nobody else is either. So, to paraphrase the immortal words of
| Bill and Ted, "be excellent to them".

Replace "a bug you report" with "a bug you want to get fixed".

This issue has been fixed and broken many times. At the moment, it seems fixed. Closing out the issue.