| Summary: | help:/ handler loses fragments | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kguiaddons | Reporter: | Harald Sitter <sitter> |
| Component: | general | Assignee: | kdelibs bugs <kdelibs-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | a.samirh78, aspotashev, roman.karwacik |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/frameworks/kguiaddons/-/commit/897f83272c2f974844bf44b28d663193b42a2fe1 | Version Fixed In: | 5.84 |
| Sentry Crash Report: | |||
*** Bug 438205 has been marked as a duplicate of this bug. *** *** Bug 426748 has been marked as a duplicate of this bug. *** https://invent.kde.org/frameworks/kguiaddons/-/merge_requests/18 This url help:/kinfocenter/index.html#kcm_memory doesn't really exist, I think it works because khelpcenter indexes all the html files in the handbook cache tarball (brief skimming of its code and looking at debug output, so not 100% sure), however when falling back to opening docs.kde.org, that indexing isn't an option, so the url has to be more precise. Both of these work with khelpcenter: help:/kinfocenter/index.html#kcm_memory help:/kinfocenter/kcm_memory.html I would argue that that second url is more accurate, as it points to an actual html file (whether it's one generated from the docbook cache.bz2 on the user's disk or it's the html file on docs.kde.org). That will probably require a mass change in .desktop files with X-DocPath. The code in KGuiAddons should now handle both cases i.e. if it gets help:/foo/index.html#bar it'll use: foo/bar.html However if we get help:/okular/index.html#adding_digital_signatures that won't work (see bug 438205), that should be fixed with https://invent.kde.org/graphics/okular/-/merge_requests/441 which basically changes the url to: help:/okular/signatures.html#adding_digital_signatures and now the openHelp() method can handle it. About percent encoding, since openHelp() interprets the url is weird ways, I am not sure percent encoding the url is needed, we process what we get if it's a #, then that is it :) (In reply to Ahmad Samir from comment #3) > https://invent.kde.org/frameworks/kguiaddons/-/merge_requests/18 > > This url help:/kinfocenter/index.html#kcm_memory doesn't really exist, I > think it works because khelpcenter indexes all the html files in the > handbook cache tarball (brief skimming of its code and looking at debug > output, so not 100% sure), however when falling back to opening > docs.kde.org, that indexing isn't an option, so the url has to be more > precise. > > Both of these work with khelpcenter: > help:/kinfocenter/index.html#kcm_memory > help:/kinfocenter/kcm_memory.html > > I would argue that that second url is more accurate, as it points to an > actual html file (whether it's one generated from the docbook cache.bz2 on > the user's disk or it's the html file on docs.kde.org). That will probably > require a mass change in .desktop files with X-DocPath. > > The code in KGuiAddons should now handle both cases i.e. if it gets > help:/foo/index.html#bar it'll use: > foo/bar.html For the url thrown at the browser? This sounds wrong. #foo is referring to an anchor on the page, not a page. e.g. https://docs.kde.org/stable5/en/kinfocenter/kinfocenter/module.html#aboutsystem which is <a name="aboutsystem"></a> When the X-DocPath is `kinfocenter/module.html#aboutsystem` it actually really needs to open https://docs.kde.org/stable5/en/kinfocenter/kinfocenter/module.html#aboutsystem I probably should have pointed that out, my example is only about "index.html", any other "foo.html" is kept. |
Some of our our software (particularly KCMs) have documentation paths set including fragments. e.g. kinfocenter's memory module has X-DocPath=kinfocenter/index.html#kcm_memory which expressed as an url will be 'help:/kinfocenter/index.html#kcm_memory'. The fragment is lost in UrlHandler::openHelp where it only picks up the path but not the fragment: const QUrl httpUrl(QStringLiteral("https://docs.kde.org/index.php?branch=stable5&language=")+QLocale().name()+QStringLiteral("&application=") + QCoreApplication::applicationName() + QStringLiteral("&path=") + url.path()); Same probably for a potential query? Also the path likely should be percent-encoded as otherwise it's unclear if the fragment applies to the master url or the path= url. e.g. the run final url should be something like https://docs.kde.org/index.php?branch=stable5&language=en_US&application=kinfocenter&path=%2Fkinfocenter%2Findex.html%23kcm_memory