You wrote:

Navigating to libstdc++ does initially scrolls to line 0237 but the scrolling gets undone when the navigation bar loads.

• Where did you click initially?
• Is the end position correct?
• Does the problem only happen on Chrome or also in other browsers?
• What happens when you use the default doxygen settings (I see that e.g. search field is removed as well as the breadcrum i.e. "blue" bar at the top).
• Do you observe the same problem when you use the current master version (1.9.2 (9d9d3bc))
• Can you please attach a, small, self contained example (source+configuration file in a tar or zip) that allows us to reproduce the problem? Please don't add external links as they might not be persistent.

You wrote:

Navigating to libstdc++ does initially scrolls to line 0237 but the scrolling gets undone when the navigation bar loads.

• Where did you click initially?

The link is on the page std::result_of.

• Is the end position correct?

The end position is line 1, not line 02373. It is incorrect. It changes after executing this line in resizeHeight:

content.css({height:windowHeight + "px"});

The navigation bar is open but empty at this point.

• Does the problem only happen on Chrome or also in other browsers?

The problem happens in Konqueror too.

• What happens when you use the default doxygen settings (I see that e.g. search field is removed as well as the breadcrum i.e. "blue" bar at the top).

I do not know how to do that. I have asked @jwakely to answer your questions.

• Do you observe the same problem when you use the current master version (1.9.2 (9d9d3bc))

No, I have no access to the API documentation typeset using the master version.

• Can you please attach a, small, self contained example (source+configuration file in a tar or zip) that allows us to reproduce the problem? Please don't add external links as they might not be persistent.

I do not know how to do it. Please understand that you have to build gcc in order to build the API documentation and that takes days to accomplish.

• I checked with Firefox and here I didn't observer any problem
• With Chrome and Microsoft edge I see problems, the link doesn't scroll down to the line 2375 but stays at the top

I looked at the resulting HTML code of https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-api.20210701.html/a00221_source.html#l02373 and see at the mentioned line:

<div class="line"><a name="l02373"></a><span class="lineno"><a class="line" href="a03925.html"> 2373</a></span>&nbsp;    <span class="keyword">struct </span><a class="code" href="a03925.html">result_of</a>;</div>

Looking at the code for a doxygen anchor I see that here not name= is used but id= and looking at:
https://www.w3schools.com/tags/tag_a.asp and https://www.w3schools.com/tags/ref_standardattributes.asp

id Specifies a unique id for an element

and the name is not mentioned as attribute.

Based on this information we can easily see the problem with other problems a well (any file will do when using SOURCE_BROWSER=YES and the scrolling will not be into the "top of the page".

(I vaguely remember that I've seen this problem in the past as will, but couldn't quickly find a reference to it).

I've just pushed a proposed patch, pull request #8650

that takes days to accomplish

No it doesn't

@jwakely Maybe you can try to compile the doxygen master with the proposed patch and see whether you still see the problem I, tried to, fix.

that takes days to accomplish

No it doesn't

Of course it does not when you have a supercomputer.

Looking at the code for a doxygen anchor I see that here not name= is used but id= and looking at:
https://www.w3schools.com/tags/tag_a.asp and https://www.w3schools.com/tags/ref_standardattributes.asp

id Specifies a unique id for an element

and the name is not mentioned as attribute.

Based on this information we can easily see the problem with other problems a well (any file will do when using SOURCE_BROWSER=YES and the scrolling will not be into the "top of the page".

(I vaguely remember that I've seen this problem in the past as will, but couldn't quickly find a reference to it).

I've just pushed a proposed patch, pull request #8650

While your change is obviously an improvement, it should be noted that Chrome does support navigating to a named anchor, which is clearly seen from the fact that it initially positions itself correctly but loses it in the process of opening the navigation bar.

Of course it does not when you have a supercomputer.

It doesn't take days on a normal laptop either. I do it all the time. Maybe you're doing it wrong.

Of course it does not when you have a supercomputer.

It doesn't take days on a normal laptop either. I do it all the time. Maybe you're doing it wrong.

Or maybe I am not rich enough to have a normal laptop.

@yecril71pl What do you mean with:

it should be noted that Chrome does support navigating to a named anchor

will the if not work or do you foresee other problems ?

It just doesn't take days, unless you do something silly like build support for every language (which is not necessary for the libstdc++ docs) without using Make's -j option (which is dumb). To build the doxygen docs you don't even need to build GCC anyway, see the maintainer-scripts/generate_libstdcxx_web_docs script in the repo which finishes in minutes (12 minutes in my laptop, and much less if you alter it to not generate the pdf versions of the docs).

Or just do this:

$gccsrcdir/configure --enable-languages=c++ --disable-gcc --disable-mulitilib --disable-lib{cc1,sanitizer,itm,gomp,vtv,ssp}
make configure-target
make -C */libstdc++-v3 doc-html-doxygen

I just tried this, and it took a minute for the configure steps and another two for the doxygen step.

Not days.

@yecril71pl What do you mean with:

it should be noted that Chrome does support navigating to a named anchor

will the if not work or do you foresee other problems ?

The id will work just as the name does, and then it will be ruined by css as it was before.

It just doesn't take days, unless you do something silly like build support for every language (which is not necessary for the libstdc++ docs) without using Make's -j option (which is dumb). To build the doxygen docs you don't even need to build GCC anyway, see the maintainer-scripts/generate_libstdcxx_web_docs script in the repo which finishes in minutes (12 minutes in my laptop, and much less if you alter it to not generate the pdf versions of the docs).

The documentation says I have to run the compiler build. Could you fix that?
-j locks my machine forever while performing ld (which uses a lot of RAM, only [SysReq[b]] works).

Or just do this:

$gccsrcdir/configure --enable-languages=c++ --disable-gcc --disable-mulitilib --disable-lib{cc1,sanitizer,itm,gomp,vtv,ssp}
make configure-target
make -C */libstdc++-v3 doc-html-doxygen

I just tried this, and it took a minute for the configure steps and another two for the doxygen step.

Not days.

Thank you very much, so I shall. I am in the process of fixing stl_function.h, so you came up with that solution just in time.

@yecril71pl you write:

The id will work just as the name does, and then it will be ruined by css as it was before.

With the, small test I did this does not happen and the position is at the right place.

• what is the base for your statement?
• did you try it?
• what did you see?

In the mean time I found a few more places with potential problems, added these changes to the proposed patch #8650

(Note: depending on the number of cores in the system the creation of the documentation might take a bit longer due to the number of images to be generated).

@yecril71pl you write:

The id will work just as the name does, and then it will be ruined by css as it was before.

With the, small test I did this does not happen and the position is at the right place.

• what is the base for your statement?

Common logic.

• did you try it?

Yes, I did.

• what did you see?

It worked. Corollary: Google Chrome defies logic. Why am I surprised?

Code has been integrated in master on github (please don't close the issue as this will be done at the moment of an official release).

FWIW the <a name="..."> attribute is deprecated in HTML 5:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#attr-name

Thanks, So Chrome and Edge are front-runners.
The patch sees to it that both name and id are present with the same anchor, so shouldn't be any problem.

We publish it as XHTML 1.0 Transitional, deprecation in HTML 5 does not apply.

This issue was previously marked 'fixed but not released',
which means it should be fixed in doxygen version 1.9.2.
Please verify if this is indeed the case. Reopen the
issue if you think it is not fixed and please include any additional information
that you think can be relevant (preferably in the form of a self-contained example).