php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #67050 Anchor goes under the heading navbar
Submitted: 2014-04-09 13:01 UTC Modified: 2023-01-09 04:22 UTC
Votes:2
Avg. Score:3.0 ± 0.0
Reproduced:0 of 2 (0.0%)
From: adrien dot dupuis at gmail dot com Assigned: levim (profile)
Status: Closed Package: Website problem
PHP Version: Irrelevant OS: Irrelevant
Private report: No CVE-ID: None
 [2014-04-09 13:01 UTC] adrien dot dupuis at gmail dot com
Description:
------------
Hi,

W/ Firefox 25.0.1, when an anchor link is clicked, the browser rightly scroll to it but it goes under the navbar so it's invisible.

For example, in http://www.php.net/manual/fr/class.domdocument.php ; if you click the first "$actualEncoding" link, it seems to show the "config" property instead of the "actualEncoding" one because this wanted one is under #head-nav.

Be aware that http://www.php.net/manual/fr/class.domdocument.php#domdocument.props.actualencoding directly pasted in the address bar doesn't behave the same as it corrects itself when DOM is ready.

Best regards,
   Adrien



Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-04-13 19:29 UTC] eric dot woelki at mymail dot champlain dot edu
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.
 [2015-06-23 15:59 UTC] levim@php.net
-Operating System: Windows 7 +Operating System: Irrelevant -Assigned To: +Assigned To: levim
 [2018-04-28 15:45 UTC] teo8976 at gmail dot com
For f***'s sake, this was "assigned" 3 years ago and is still not fixed!
 [2018-04-28 16:02 UTC] levim@php.net
... do you think I get paid for this or sighing?
 [2018-04-28 16:23 UTC] levim@php.net
Ha, wrote that last comment on mobile; meant to say "or something?"
 [2018-04-28 17:05 UTC] teo8976 at gmail dot com
> 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.
 [2018-04-28 17:40 UTC] levim@php.net
> 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?
 [2018-04-28 18:03 UTC] teo8976 at gmail dot com
> 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).
 [2018-04-28 18:14 UTC] teo8976 at gmail dot com
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.
 [2018-04-28 18:27 UTC] levim@php.net
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.
 [2018-04-29 00:01 UTC] cmb@php.net
@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>
 [2018-04-29 15:14 UTC] teo8976 at gmail dot com
> @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.
 [2018-04-29 15:26 UTC] teo8976 at gmail dot com
> 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.
 [2018-04-29 20:48 UTC] cmb@php.net
> 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".
 [2023-01-09 04:22 UTC] levim@php.net
-Status: Assigned +Status: Closed
 [2023-01-09 04:22 UTC] levim@php.net
This issue has been fixed and broken many times. At the moment, it seems fixed. Closing out the issue.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Nov 10 22:01:28 2024 UTC