I confirm to have the very same problem: I generate the HTML without treeview (because I pack all in a CHM file, so there's no need of treeview) but the class methods documentation pages are broken because doxygen produces invalid HTML (without the closing <div> and <ul> for the nav-path bar).

Thanks in advance if you will fix the issue in a "binary way" (can you produce a patch for the binary executable on windows?), I really would like to be able to set a custom footer for my documentation.

Should I otherwise wait for the next binary release of Doxygen? Or can you attach a patched version of the installer or executable maybe?
Again, Thanks a lot in advance for your cooperation and help.

Best regards

Edoardo

[OS in use: Windows 7 32bit]

(In reply to comment #0)
> Created an attachment (id=179609) [details] [review]
> Patch to close navbar HTML tags correctly
> 
> If you set a custom footer (HTML_FOOTER) and don't output a tree view
> (GENERATE_TREEVIEW off), the output HTML is corrupt. The <div> and <ul> HTML
> tags for the nav-path bar (breadcrumb) are not closed correctly. This
> navigation bar is used when viewing the code or documentation of a specific
> file, and is placed above the content if GENERATE_TREEVIEW is off.
> 
> To make the problem occur, create a custom footer file with some text and the
> closing </body> and </html> tags. The HTML will be invalid, even if the footer
> does start with closing the two tags in question.
> 
> It does not cause visible problems if GENERATE_TREEVIEW is on, due to the fact
> that the navigation bar is placed at the end of the document, which means the
> footer can close any open tags (I'll add a separate bug about this; there is a
> mistake in the manual regarding the custom footer).
> 
> Attached patch solves the issue.

I downloaded and compiled Doxygen, but the patch you posted doesn't seem to avoid the problem.
This is my code in the definition.cpp:

void Definition::writeNavigationPath(OutputList &ol) const
{
  static bool generateTreeView = Config_getBool("GENERATE_TREEVIEW");
  static bool hasCustomFooter = !Config_getString("HTML_FOOTER").isEmpty();

  ol.pushGeneratorState();
  ol.disableAllBut(OutputGenerator::Html);

  if (generateTreeView)
  {
    ol.writeString("</div>\n");
  }

  ol.writeString("  <div id=\"nav-path\" class=\"navpath\">\n");
  ol.writeString("    <ul>\n");
  writePathFragment(ol);
  if (!hasCustomFooter && generateTreeView)
  {
    ol.writeString("      <li class=\"footer\">");
    ol.writeLogo();
    ol.writeString("</li>\n");
  }

  if (!hasCustomFooter || !generateTreeView)
  {
    ol.writeString("    </ul>\n");
    ol.writeString("  </div>\n");
  }

  ol.popGeneratorState();
}

Can you help me? I compiled using Qt 4.6.2, debugging doesn't let me stop in the .cpp file and I don't know why...

P.S.: Please use environment variables in the VC Projects for Windows, because there were absolute paths to Qt for RCC, MOC and includes. Ex.:
"$(QTDIR)\include\QtCore",
not "C:\Qt\4.4.3\include\QtCore" or "..\..\..\Qt\4.4.3\include\QtCore" (that force the user to have a fixed Qt version and path).

Dont't ask how, but now that i Rebuilt all the Doxygen solution and I have regenerated my intermediate documentation (deleting the folder before executing doxywizard), all went OK and your patch proved to work (I use the previously posted code for the writeNavigationPath() in 'definition.cpp').
Sorry for the inconvenience, but I still can't understand what happened in the meanwhile.


I also noticed the following code from "index.cpp" (lines [316,343]), that I changed (changed lines [335,337]):

void endFile(OutputList &ol,bool skipNavIndex)
{
  static bool generateTreeView = Config_getBool("GENERATE_TREEVIEW");
  static bool hasCustomFooter = !Config_getString("HTML_FOOTER").isEmpty();
  ol.pushGeneratorState();
  ol.disableAllBut(OutputGenerator::Html);
  if (!skipNavIndex)
  {
    ol.endContents();
    if (generateTreeView)
    {
      ol.writeString("</div>\n");
      ol.writeString("  <div id=\"nav-path\" class=\"navpath\">\n");
      ol.writeString("    <ul>\n");
      if (!hasCustomFooter)
      {
        ol.writeString("      <li class=\"footer\">");
        ol.writeLogo();
        ol.writeString("</li>\n");
      }
      ol.writeString("    </ul>\n");
      ol.writeString("  </div>\n");
    }
  }
  ol.writeFooter(); // write the footer
  ol.popGeneratorState();
  ol.endFile();
}

As you can see (maybe doing a diff with your 'endFile()' method), I extracted the two lines that adds the closure tags for <ul> and <div> from the "if(!hasCustomFooter)", because I think they should be executed even if the user has set a custom footer; this to close the previously opened tags (tags opened even if the user had a custom footer, because it's not controlled).

Do you think this is correct? Is this a bug-fix too?

Thanks a lot for any reply.

Note that the with a treeview, the footer contents is expected to be in the <ul> of the navigation path. So the custom footer is also expected to close the ul and div of the nav-path, if a tree view is generated. The footer content normally appears at the right of the navigation bar (the "Generated by Doxygen ..." message). Check out the default generated output to see what I mean.

All in all, I think the changes in comment 3 are incorrect.

Note that this bug report is about the case when there is NO tree view: the nav-path appears above the content, but isn't closed properly if a custom footer is used. The footer is still placed after the content, and is unable to close the open tags properly in that situation. Basically the entire content is placed inside the nav-path list, which is wrong.

Thanks a lot for the answer, I appreciate it (and now it's more clear for me).

About the binary patch, do you think it will be possible (I compiled it, so for me there's no problem any more, but for the rest of doxygen user it's still there..)? What's your policy in these cases (do you wait to add it to the next release, 1.7.4)?


About Doxygen's VisualStudio project file, I'd like to help inserting relative paths with environment variable to include Qt (from $(QTDIR), which I already modified in my projects to compile); you think you can do it or you prefer me to attach my projects, or you don't even want to do the modification?

I think that's a very useful thing (to use environment variables), because it's very portable (naturally in this case only across Microsft OSs, because it's in VisualStudio Project settings; but in general environment variables are a good idea for project settings), and using them don't force the user to have for example a determinate Qt version (es. "4.4.3" as the one in current settings - I use "4.6.2") nor to have it in a determined filesystem position (like "../../Qt 4.4.3/", as now it's in the settings).
The only thing to ask is to have an environment variable QTDIR that points to the Qt installation path, and if the user used an installer for Qt, should be already set.

Thanks again for the answer and the work you do, and if you mind, let me please know about the eventual binary patch and about the VS project settings.

Cheers

Can anyone tell me if this patch is still needed with the latest subversion update?

I REALLY NEED this patch. I spend too much time about this problem.
Anyway, I'm glad this bug is fixed. I hope you support binary version patch.
Thank you. :)

I REALLY NEED this patch. I spend too much time about this problem.
Anyway, I'm glad this bug is fixed. I hope you support binary version patch.
Thank you. :)

The problem still seems to occur with the latest svn version. Applying the patch also still fixes the problem, so it's still necessary.

Can anyone commit the patch? I'm not a doxygen developer, so I can't commit, but I'd like to find it in the next binary release.

Thanks a lot


[P.S.: I work with VisualStudio for C++ 3D graphics projects, so I'd like to contribute to your Windows version of the projects (.vcproj - I noticed the path problems previously mentioned applying this patch and recompiling doxygen): do you use a tool to generate them (the .vcproj files)? Where can I talk about this topic? I know this isn't the right thread to talk about this subject, so I would like someone to address me right... thank you in advance for any help]

Changed version 'latest' to '1.8.2-SVN' so I can remove 'latest' as an option as it is a moving target.

As discussed in https://github.com/doxygen/doxygen/pull/734 , Doxygen has moved its issue tracking to 

   https://github.com/doxygen/doxygen/issues

All Doxygen tickets in GNOME Bugzilla have been migrated to Github. You can subscribe and participate in the new ticket in Github. You can find the corresponding Github ticket by searching for its Bugzilla ID (number) in Github.

Hence I am closing this GNOME Bugzilla ticket.
Please use the corresponding ticket in Github instead. Thanks a lot!