Bug Hunting Session
Bug 126641 - Hyperlink to bookmark in doc[x] file does not work
Summary: Hyperlink to bookmark in doc[x] file does not work
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.2.4.2 release
Hardware: All Windows (All)
: medium normal
Assignee: Mike Kaganski
URL:
Whiteboard: target:6.4.0 target:6.3.1 target:6.2.7
Keywords: bibisected, bisected, regression
Depends on:
Blocks: DOCX-Hyperlink
  Show dependency treegraph
 
Reported: 2019-07-31 15:01 UTC by Bigor
Modified: 2019-09-05 12:08 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bigor 2019-07-31 15:01:23 UTC
Description:
Hyperlink to bookmark in doc file does not work When you click on the hyperlink to the bookmark in the doc file, the window appears: "file:///C:/test/test.docx#z1 is not an absolute URL that can be passed to an external application to open"

Steps to Reproduce:
1.created a hyperlink
2.We pass on it
3.

Actual Results:
 When you click on the hyperlink to the bookmark in the doc file, the window appears: "file:///C:/test/test.docx#z1 is not an absolute URL that can be passed to an external application to open"

Expected Results:
to open the document at the link


Reproducible: Always


User Profile Reset: No



Additional Info:
Comment 1 Mike Kaganski 2019-08-01 09:04:29 UTC
The problem here is two-fold.

1. There is a regression from https://git.libreoffice.org/core/+/d59ec4cd1660410fa1b18c50d2d83b1417a82ddc, which results in the failure to open the link. It is addressed in https://gerrit.libreoffice.org/76778.

2. There is a problem that even when it opens the document, it doesn't follow to the bookmark. That's because, despite LibreOffice is able to open file: URLs with fragment, the code that processes the URL (CSysShExec::execute) calls system function ShellExecuteExW, which internally converts the passed file: URL (like file:///C:/test/test.docx#z1) into system file path (like C:\test\test.docx), and strips the fragment part. No idea how to address that at the moment.

Taking only the first part. I will close this bug after the fix, and suggest that the second part be tracked individually in another bug report.

Thanks for reporting!
Comment 2 Xisco Faulí 2019-08-01 09:20:08 UTC
let's mark it as a regression then.
@Mike, thanks for taking care of it
Comment 3 Commit Notification 2019-08-01 12:50:11 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/2207269a84c7c9920af3385b837ce67978c720b4%5E%21

tdf#126641: don't fail on file URLs with fragment

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 4 Mike Kaganski 2019-08-01 12:58:41 UTC
As I mentioned, the rest should be tracked independently.

One idea for someone who could try to implement handling the fragment:

we could ask for the system-configured handler application for the file type (using AssocQueryStringW [1]); then take our own executable, and check if the handler is one of our exe files (in the process, testing if two paths are pointing to the same file might be required, e.g. using std::filesystem::equivalent [2]); and in case when we determined that it's this application that opens the document, we could bypass the system call, and open the URI directly, passing the fragment along, which would result in us navigating to it ...

and immediately I see a problem: even when the executable is one of ours, what about possibly configured user environment path? that could result in a different process with different settings, so the workaround would break that. Too many aspects to consider; not something I am going to work on in foreseeable future.

[1] https://docs.microsoft.com/en-us/windows/win32/api/shlwapi/ne-shlwapi-assocstr
[2] https://en.cppreference.com/w/cpp/filesystem/equivalent
Comment 5 Commit Notification 2019-08-02 15:39:03 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-6-3":

https://git.libreoffice.org/core/+/dd2b7919058fc0e23a7117d39110d3ecaaad1fb2%5E%21

tdf#126641: don't fail on file URLs with fragment

It will be available in 6.3.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 6 Commit Notification 2019-08-06 09:30:00 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-6-2":

https://git.libreoffice.org/core/+/72861eaf7cf9af3e7764b13d9e74edc5548806d2%5E%21

tdf#126641: don't fail on file URLs with fragment

It will be available in 6.2.7.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.