Description: When exporting documents including hyperlinks with HTTP basic authentication credentials from any application (tested with Draw, Writer and Calc) to PDF, the hyperlink gets lost and somehow points to local resources/paths which cannot be found. Steps to Reproduce: 1.Create a hyperlink in any document in the format of http://username:password@example.com 2. Open the link to confirm it is working by CTRL+clicking the link (this works from within LibreOffice) 3. Export the document to PDF via File - Export as... - Export as PDF 4. Open the exported PDF 5. Try to open the hyperlink with basic auth credentials from within the PDF viewer (tested: Okular, SumatraPDF under Wine) Actual Results: Either the PDF viewer says it can't find the specified local resource or opens some random path in the file manager (in my case thunar) Expected Results: The link should be opened in the default web browser and try to log in to the website requiring HTTP basic authentication using the provided credentials. Reproducible: Always User Profile Reset: Yes Additional Info: Version: 7.1.4.2 / LibreOffice Community Build ID: 10(Build:2) CPU threads: 8; OS: Linux 5.12; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: de-DE 7.1.4-1 Calc: threaded
Created attachment 173390 [details] LibreOffice Draw Document containing a hyperlink with HTTP basic auth credentials
Created attachment 173391 [details] PDF generated from LibreOffice Draw document containing a hyperlink with HTTP basic auth credentials
I can reproduce with the sample file in comment #1 and 7.0.6: Version: 7.0.6.2 (x64) Build ID: 144abb84a525d8e30c9dbbefa69cbbf2d8d4ae3b CPU threads: 2; OS: Windows 10.0 Build 19041; UI render: default; VCL: win Locale: zh-CN (zh_CN); UI: en-US Calc: threaded There are many options in the "Export as PDF" dialog, "Links" tab, and I only tested "Default mode" and "Open with Internet Browser" for "Cross-document Links". Doesn't seem to make a difference, in both cases the link in the PDF points to a (non-existent) local URL. I'm not familiar with the PDF exporting feature though, and there are many options I didn't test, so leaving this at UNCONFIRMED.
no repro in Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: c5ca46e75e28ba4245d8544ca53c71fea87d1bbd CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL p.s. the link opens in default browser (Microsoft Edge Ver. 91.0.864.71 (official) (64-xx)) and asks for authorization to login
I can reproduce this on current git head; it's kind of fun - It almost feels like there's two links in the output - one that's a broken file link , and the 2nd that's a mailto.
Looking at the generated pdf, uncompressed with podofouncompress I see: /URI (./https:%2F%2Fusername:password@example.com) Note the './' at the start - so something thinks it's dealing with a relative path. I looked at pdfwriter_impl.cxx:emitLinkAnnotations and it has: if( m_aContext.RelFsys && eBaseProtocol == eTargetProtocol && eTargetProtocol == INetProtocol::File ) bSetRelative = true; printing those values and we see: PDFWriterImpl::emitLinkAnnotations RelFSys: 1 eBaseProtocol: 3 eTargetProtocol: 3 and looking at urlobj.hxx, InetProtocol::File is 3 - so yep, that's been misparsed as a relative file path; not sure by what yet.
This looks too easy...but; turning on the m_bUser and m_bPassword flags in urlobj.cxx getSchemeInfo seems to pass a smoke test and produce a pdf with the correct output; I'll check it tomorrow...erm later. @@ -341,7 +343,7 @@ INetURLObject::getSchemeInfo(INetProtocol eTheScheme) "vnd.sun.star.help", "vnd.sun.star.help://", true, false, false, false, false, false, true, true}, SchemeInfo{ - "https", "https://", true, false, false, false, true, true, + "https", "https://", true, true, false, true, true, true, true, true}, SchemeInfo{ "slot", "slot:", false, false, false, false, false, false, false,
Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9579737b36e5055d5eb72abc0ace2b9b65600c76 tdf#143216: pdfwriter: Don't treat semi-valid URIs as local paths 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.
@buovjaga: <https://bugs.documentfoundation.org/show_activity.cgi?id=143216> has the line > ilmari.lauhakangas@libreoffice.org 2022-02-14 08:18:52 UTC Version unspecified 7.0.6.2 release but without any further explanation here. Is this issue actually a regression?
(In reply to Stephan Bergmann from comment #9) > @buovjaga: <https://bugs.documentfoundation.org/show_activity.cgi?id=143216> > has the line > > > ilmari.lauhakangas@libreoffice.org 2022-02-14 08:18:52 UTC Version unspecified 7.0.6.2 release > > but without any further explanation here. Is this issue actually a > regression? That's based on comment 3
Dr. David Alan Gilbert committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/da7b06425155938fb0d02c6c178d63fd95ad0cd4 tdf#143216: pdfwriter: Don't treat semi-valid URIs as local paths It will be available in 7.3.3. 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.
OK, that should have fixed it.