New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GENERATE_TREEVIEW breaks the back button in several browsers (Origin: bugzilla #685940) #4921

doxygen opened this Issue Jul 2, 2018 · 0 comments


None yet
1 participant

doxygen commented Jul 2, 2018

status RESOLVED severity major in component general for ---
Reported in version 1.8.2-SVN on platform Other
Assigned to: Dimitri van Heesch

Original attachment names and IDs:

On 2012-10-11 09:15:00 +0000, Philipp Moeller wrote:

Created attachment 226239
A Doxyfile an example class to reproduce the issue.

When GENERATE_TREEVIEW is enabled the back button in several browsers (Firefox, Chrome, Safari) doesn't behave as intended after jumping to a detailed member description. The exact steps to reproduce are as follows:

doxygen Doxyfile
firefox html/index.html
Navigate to "Class", then to "X"
click the "what" member of X (jumps down to the detailed description of what)
click the back button of the browser (nothing happens)
click the back button again (jumps back to "Classes")

The expected behavior after using the Back Button would be to jump to the position the window was at before clicking the member. The correct behavior can be observed with GENERATE_TREEVIEW = NO.

This is a major annoyance in class documentation with many members.

Attached is an example with a lot of pseudo-text in a class documentation and an enabled treeview where this can be reproduced in classX.html.

As far as I can tell this is related to the rewriting of $(window).location performed by navtree.js.

On 2012-10-12 16:46:26 +0000, Philipp Moeller wrote:

The issue seems to be that overflow: auto used in navtree.css for #doc-content. Removing it breaks the layout, but restores the back button functionality. This is also reproducible in smaller layouts. Is this the expected behavior?

On 2012-10-18 15:47:57 +0000, Philipp Moeller wrote:

My current workaround is to rewrite the css for the top and footer divs using position: fixed. After that it is necessary to pad the doc-content div with the header and footer height. A css trick has to be applied to make the anchors respect the padding (This could be avoided by having two divs just for padding inside doc-contents). This has the drawback of not working on IE6, but this is not really a problem for me. This also makes some of the code in resize.js (which should be merged into navtree.js and the main NAVTREE variable should be moved to a separate file to enable colocation of more js files) unnecessary.

All this is currently done through external stylesheets and overwriting of some of the javascript code, but could be factored into the generator code.

On 2012-10-28 09:15:49 +0000, Dimitri van Heesch wrote:

I think I found a better solution which only impacts the navtree.js. I will include this in the next subversion update.

On 2012-12-26 16:09:11 +0000, Dimitri van Heesch wrote:

This bug was previously marked ASSIGNED, which means it should be fixed in
doxygen version 1.8.3. Please verify if this is indeed the case. Reopen the
bug if you think it is not fixed and please include any additional information
that you think can be relevant.

On 2016-07-28 20:53:14 +0000, LorenaGdL wrote:

Hello Dimitri,

This is still an issue. I can reproduce it with your own Doxygen documentation, in Chrome and IE. Others have told me they have reproduced the issue in Firefox too. Did you finally apply the patch? If you need extra information, please let me know.

Thanks in advance

@doxygen doxygen closed this Jul 2, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment