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: Calc (show other bugs)
Version:
(earliest affected)
4.1.0.0.alpha0+ Master
Hardware: Other Windows (All)
: medium critical
Assignee: Kohei Yoshida
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:
Crash report or crash signature:


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

Note You need to log in before you can comment on or make changes to this bug.
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 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."