Description: we use a custom protocol handler to link internal links, i.e. intern://some/other/file this works nicely, but it fails when the link ends with .ods or .odt: intern://some/other/file.ods in the second case the protocol handler isn't started. when i change .ods to .pdf it works: intern://some/other/file.pdf Steps to Reproduce: 1. register custom protocol handler so that it runs on windows with "start intern://" or on linux with "xdg-open intern://" 2. create a hpyerlink in writer/calc intern://test.ods 3. ctrl+click on it Actual Results: external handler isn't started when url ends with .ods or .odt Expected Results: external handler is started Reproducible: Always User Profile Reset: Yes Additional Info: replacing the .ods with %2Eods makes it work.
Created attachment 165077 [details] dokument with broken and working link
On which env are you? (Windows, Linux or Mac) Could you give a try with last stable LO version 6.4.6? Indeed 6.2 and 6.3 branches are EOL.
Created attachment 165078 [details] protocol handler file for linux place into ~/.local/share/applications/ run update-desktop-database ~/.local/share/applications/ and verify with xdg-open intern://
i'm on linux, but this fails on windows to. with libreoffice 7.0.1.1 this problem can be reproduced, too.
Ok thank you for your feedback. Since I don't have more questions, let's put this one back to UNCONFIRMED. Since I don't protocol handler, I can't help here=>uncc myself. Certainly other people may help.
with libreoffice 7.0.1.1 i get the error message: "This operation is not supported on this operating system."
Well, in sfx2/source/appl/appopen.cxx in the SfxApplication::OpenDocExec_Impl method: 845 const OUString aTypeName { xTypeDetection->queryTypeByURL( aURL.Main ) }; 846 SfxFilterMatcher& rMatcher = SfxGetpApp()->GetFilterMatcher(); 847 std::shared_ptr<const SfxFilter> pFilter = rMatcher.GetFilter4EA( aTypeName ); 848 if (!pFilter || !lcl_isFilterNativelySupported(*pFilter)) 849 { 850 // hyperlink does not link to own type => special handling (http, ftp) browser and (other external protocols) OS ... 908 sfx2::openUriExternally( 909 aURL.Complete, pFilter == nullptr); queryTypeByURL is the so-called "flat" type detection, which returns the file type based solely on the file extension. So basically we pass the link to an external OS handler only if the extension isn't of a native LO file type. The reason is that we want to load native documents internally as documents, not to open them in an external app. One possible solution might be to limit this native format handling to a set of known protocols, or even just to file://. But I'm not familiar with this hyperlink stuff, so don't know whether it's a good idea to change anything here, or what scenarios we attempt to support.
(In reply to Maxim Monastirsky from comment #7) It definitely makes sense to limit own handling to protocols that we support (we will simply be unable to reach the document using anything else) - and that means that for any unknows scheme we must fallback to OS to handle those. For the sake of testing, no custom handler is needed e.g. on Windows: just add two hyperlinks to a text document: foo://path/to/document.ext foo://path/to/document.odt and Ctrl+click on both. The first one would show a prompt to find an application handling "foo" link, while the second will do nothing. The code pointer is in comment 7 => marking easyhack.
I'll be attempting to to resolve this. In my opinion restricting to `file://` only should be fine, as loading a document over HTTP seems like an extremely niche usecase, and possibly unexpected behaviour? Any comments or suggestions?
(In reply to Adityarup Laha from comment #9) > In my opinion restricting to > `file://` only should be fine, as loading a document over HTTP seems like an > extremely niche usecase, and possibly unexpected behaviour? Any comments or > suggestions? No. Loading a document over HTTP is exactly what WebDAV is about.
(In reply to Mike Kaganski from comment #10) > (In reply to Adityarup Laha from comment #9) > > In my opinion restricting to > > `file://` only should be fine, as loading a document over HTTP seems like an > > extremely niche usecase, and possibly unexpected behaviour? Any comments or > > suggestions? > > No. Loading a document over HTTP is exactly what WebDAV is about. So, "file://", "ftp://", "http://", "https://" ought to be sufficient?
I've submitted a patch addressing this issue, any feedback will be very helpful. :)
(In reply to Adityarup Laha from comment #12) > I've submitted a patch addressing this issue, any feedback will be very > helpful. :) Oops, I forgot to link to the patch. Here it is: https://gerrit.libreoffice.org/c/core/+/131449
Adityarup Laha committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/69656132a00491b96da3a898c350f11e9619da64 tdf#136427: Attempt opening native documents for known protocols only. It will be available in 7.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.
i've retested with LO 7.4.5.1 on Linux and it still doesn't work: with: foo://bug.ods nothing happens on click. with: foo://bug.pdfs an error message "not supported protocol" from "exo-open" as excepted.
(In reply to Commit Notification from comment #14) > Adityarup Laha committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > 69656132a00491b96da3a898c350f11e9619da64 INetProtocol::NotValid covers completely broken link targets. For example: intern$broken Note: "$" is needed in the example to keep LO from automatically assuming http:// The intern://test.ods example is INetProtocol::Generic instead. So I guess if (aINetProtocol != INetProtocol::NotValid && aINetProtocol != INetProtocol::Generic) { would be the correct solution.
(In reply to kolAflash from comment #16) Nice catch! Please submit a patch for review. Thanks!
(In reply to kolAflash from comment #16) > So I guess > if (aINetProtocol != INetProtocol::NotValid && aINetProtocol != > INetProtocol::Generic) { > would be the correct solution. INetPRotocol::Generic is used e.g. for URL schemes like smb and sftp that are handled (on Linux/GNOME at least) by the gvfs UCP. We probably want to keep treating <sftp://example.com/file.ods> the same way as, say, <http://example.com/file.ods> here.
Maybe a different approach is possible. Instead of excluding protocols preliminary, LO could check if a URI was successfully internally opened. And if is was not successfully internally opened, LO opens the URI externally. I think this is where at least HTTP URLs get opened: https://git.libreoffice.org/core/+/0fcb5d2fcb46214b3182f7837a99725f02b7bd61/sfx2/source/appl/appopen.cxx#1085 xDisp->dispatch( aURL, aArgs );