Bug 61332 - FILEOPEN other document via document-hyperlink in LibO3.6-document fails with error message
Summary: FILEOPEN other document via document-hyperlink in LibO3.6-document fails with...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Spreadsheet (show other bugs)
Version: 4.1.0.0.alpha0+ Master
Hardware: Other Windows (All)
: medium critical
Assignee: Kohei Yoshida (inactive)
QA Contact: Florian Reisinger
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: mab4.1
  Show dependency treegraph
 
Reported: 2013-02-23 08:44 UTC by Rainer Bielefeld Retired
Modified: 2013-04-10 15:28 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Test Kit (27.32 KB, application/zip)
2013-02-23 08:44 UTC, Rainer Bielefeld Retired
Details

Description Rainer Bielefeld Retired 2013-02-23 08:44:16 UTC
Created attachment 75396 [details]
Test Kit

Steps how to reproduce with parallel Dev-installation of  "Version 4.1.0.0.alpha0+ (Build ID: 0a967d4cb4468785ed3d302104642353b93232f) TinderBox: Win-x86@6, Branch:master, Pull Time: 2013-02-21_00:36:59" ENGLISH UI / German Locale  on German WIN7 Home Premium (64bit) with LODev/4 Masters User Profile :

0. Download / unzip attached test kit
1. Launch LibO-Dev
2. Open "Document with link from LibO365.ods" from LibO Start center
   > Shows a cell with a hyperlink
3. click link (wiht pressed <control> if necessary because of your 
   security settings)
   Expected: Linked document will be opened
   Actual: error message (see below=

More observations:
--------------------
It seems LibO now distinguishes between absolute and relative links. In old versions always a conplete path like "file:///C:/Users/....." was shown in hyperlink dialog and tooltip without attention whether link is relative or absolute. In "Document with link_410.ods" in test kit you see different tooltips for both links.
Not a problem in Writer (see "DocumenWithLink.odt")

Still [Reproducible] parallel Dev-installation of  "Version 4.1.0.0.alpha0+ (Build ID: fd56eb98e63b4aac12c9633d5847a3fb964f326) TinderBox: Win-x86@6, Branch:master, Pull Time: 2013-02-22_21:43:36" ENGLISH UI / German Locale  on German WIN7 Home Premium (64bit) with LODev/4 Masters User Profile 

Already [Reproducible] with Version 4.1.0.0.alpha0+ (Build ID: 134374473ea481410f389cab162a52fab62c5c4)
TinderBox: Win-x86@7-MinGW, Branch:master, Time: 2013-02-17_23:52:45

Was still ok with server installation of  "Version 4.1.0.0.alpha0+ (Build ID: 576da8db5577f84d9c7e0e40ef3e166a7938c98) TinderBox: Win-x86@6, Branch:master, Pull Time: 2013-02-11_23:54:45" ENGLISH UI / German Locale  on German WIN7 Home Premium (64bit) with own separate User Profile.



Error Message in Step 3:
------------------------
"../Targetfolder/Target.ods" is not an absolute URL that can be passed to an external application to open it.
Comment 1 Rainer Bielefeld Retired 2013-02-23 08:57:59 UTC
some good news: linked pictures are not affected
Comment 2 Florian Reisinger 2013-02-23 17:33:16 UTC
Hi!

Tested with Version 4.1.0.0.alpha0+ (Build ID: fd56eb98e63b4aac12c9633d5847a3fb964f326)
TinderBox: Win-x86@6, Branch:master, Time: 2013-02-22_21:43:36 @ Win 7 x64

Absolute path didn't work too, because the dir obviously not exists

Working with Version 4.0.0.3 (Build ID: 7545bee9c2a0782548772a21bc84a9dcc583b89)....
Comment 3 Stephan Bergmann 2013-04-09 08:15:38 UTC
The attached "Document with link from LibO365.ods"'s content.xml contains a relative link,

  <text:a xlink:href="../Targetfolder/Target.ods" xlink:type="simple">link</text:a>

and opening the .ods with a recent Linux master build, the relative URL is still turned into an absolute file URL there.

So it looks like the code that reads ODF xlink:href (wherever that is) for some reason no longer works for relative URLs on Windows.
Comment 4 Stephan Bergmann 2013-04-10 13:12:43 UTC
(In reply to comment #3)
> So it looks like the code that reads ODF xlink:href (wherever that is) for
> some reason no longer works for relative URLs on Windows.

SvXMLImpot::GetAbsoluteReference (xmloff/source/core/xmlimp.cxx) apparently is not the right place to track down why Windows behaves differently here; it returns an absolute file URL when running the bug scenario on both Linux and Windows recent master builds.

Kohei, do you have any idea where this could be broken?
Comment 5 Kohei Yoshida (inactive) 2013-04-10 13:24:51 UTC
I fixed this on Monday as part of a fix for Bug 62116.  Try a Windows build that contains the fix.  There should not be any platform-specific handling here.
Comment 6 Stephan Bergmann 2013-04-10 15:28:04 UTC
(In reply to comment #5)
> I fixed this on Monday as part of a fix for Bug 62116.  Try a Windows build
> that contains the fix.  There should not be any platform-specific handling
> here.

Indeed, seen this working now with a recent Windows master build that includes <http://cgit.freedesktop.org/libreoffice/core/commit/?id=d64b5cc1c3d232ba42479fe0a3c186ecabd25144> "fdo#62116: Be sure to convert relative URLs into absolute ones."


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.