Regression: Doxygen >= 1.11.0 no longer able to produce .chm files that link to each other using TAGFILES

[puetzk]

Describe the bug
PR #10860 introduced a restriction that .chm files should only be able to link to http/https URLs, in an attempt to fix #6217

I think this check is too strong. In particular, it bans the "ms-its:" URL scheme IE uses for linking into .chm files (and since .chm files use the MSHTML render, this is the means by which a set of separate-but-related related .chm files would link into each other, which is what TAGFILES is all about.

See https://learn.microsoft.com/en-us/previous-versions/windows/desktop/htmlhelp/about-html-help-urls

To Reproduce

Doxygen-TAGFILES-ms_its.zip

doxygen Doxyfile.foo.doxygen.chm -> generates foo.doxygen.chm and foo.doxygen.tags
doxygen Doxyfile.bar.doxygen.chm -> generates bar.doxygen.chm

doxygen 1.10 works as intended, producing a bar.doxygen.chm in which both of those mentions of Foo (in the signature and in the description) are links to ms-its:foo.doxygen.chm::/class_foo.html, which will open the corresponding page in foo.doxygen.chm in the same browser frame/instence of hh.exe.

void bar (Foo *foo)
Oh the things you could do, if you had a Foo.

Caveat: there's some further interactions here between ms-its:, IE's Local Zone lockdown and the "Mark of the web" (Zone.Identifier proprety). If the "bar.chm" file has a "Zone.Identifier" identifying it as downloaded from some website, then the browser isn't allowed follow these links to other local files, even if those other files bear the same "mark of the web" domain. So admittedly this is only usable between .chm files generated locally, or shipped as part of an installer, etc - loose files downloaded by a browser often end up with their links broken unless you do the File : Properties : General : Unblock in explorer to release them from quarantine. But I think caring about that kind of browser security feature is beyond the doxygen's scope - it generated a file that works fine, unless blocked by a cross-domain security measure.

Doxygen 1.14 instead produces a message

error: When enabling GENERATE_HTMLHELP the TAGFILES option should only contain destinations with https / http addresses (not: C:/projects/FOCUS/cmake-modules/test_package/build/c7f45969132fb10262d928e75a5e32d61659d7c6/Doxygen/foo.doxygen.chm_html/foo.doxygen.tags=ms-its:foo.doxygen.chm::/). I'll adjust it for you.

And it "adjusts" it by simply dropping references from TAGFILES it doesn't like:
https://github.com/albert-github/doxygen/blob/fdc83520473504e7acdf5f70970b478dc90b195c/src/configimpl.l#L2007-L2014

Which makes there be no tagfile referenced, and Foo no longer be a link to anything.

Expected behavior

I think this check should also accept the ms-its: protocol, since that's a documented part of HTML Help.

Version
Last known working: Doxygen 1.10
1.12, 1.13, and 1.14 are all known bad (I didn't actually have an installation of 1.11 handy, but assume it is also affected based on the timing of #10860

[albert-github]

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

Some remarks:

• The HTML Help is already a long time out of support / maintenance (and the documentation of the old version was also not quite clear)
• when switching to "Foo" one sees that the left pane (with the tree) is not updated and stays with the information of the original chm file
• a 1.11.0 release can be obtained from https://github.com/doxygen/doxygen/releases/tag/Release_1_11_0

[puetzk]

The HTML Help is already a long time out of support / maintenance

Granted. We also publish are docs as loose HTML and various other forms. But .chm files remain one of the nicer (single-file) ways of distributing it.

when switching to "Foo" one sees that the left pane (with the tree) is not updated and stays with the information of the original chm file

Correct (or at least as expected). You didn't actually switch and open the other library, just clicked on and followed a deep link in the details "frame".

[puetzk]

#11274 looks unrelated, I assume you meant to link #11741?

[albert-github]

Yes I did.

[albert-github]

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).

[doxygen]

This issue was previously marked 'fixed but not released',
which means it should be fixed in doxygen version 1.15.0.
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).