<html>
<head>
<base href="https://bugs.documentfoundation.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_UNCONFIRMED "
title="UNCONFIRMED - Relative links broken in Calc"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=126255">126255</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Relative links broken in Calc
</td>
</tr>
<tr>
<th>Product</th>
<td>LibreOffice
</td>
</tr>
<tr>
<th>Version</th>
<td>6.4.0.0.alpha0+ Master
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>UNCONFIRMED
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>Calc
</td>
</tr>
<tr>
<th>Assignee</th>
<td>libreoffice-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>glogow@fbihome.de
</td>
</tr></table>
<p>
<div>
<pre>Description:
I didn't test other components. The origin of this bug is the failing tinderbox
Win-x86_64_42.
In commit 3f7e8ddea89f ("Enable many more unit tests on all archs") I enabled
many more unit tests an all archs to verify if any arch specific #ifdefs are
still needed and fixed some fallout, Jenkins didn't catch in commit
a2c665e4dd73 ("WIN fix some unit tests more generally").
But there is one problem left: Win-x86_64_42 fails with
24952 NEXT D:/lode/dev/core/sc/qa/unit/subsequent_export-test.cxx(3086) :
error : Assertion
24953 Test name: ScExportTest::testRelativePathsODS
24954 NEXT assertion failed
24955 - Expression: aURL.startsWith("..")
24956
24957 Failures !!!
24958 Run: 115 Failure total: 1 Failures: 1 Errors: 0
Thorsten thankfully added a SAL_DEBUG on that box, which shows:
<span class="quote">> $ grep debug workdir/CppunitTest/sc_subsequent_export_test.test.log
> debug:4516:2084:
> file:///D:/lode/dev/core/sc/qa/unit/data/ods/xlsx/databar.xlsx</span >
So obviously the test fails. But it's actually broken on all architectures.
Just open the bug document of the unit test: sc/qa/unit/data/ods/fdo79305.ods.
It just contains a
link as
<text:a xlink:href="../xlsx/databar.xlsx"
xlink:type="simple">/devel/libo/libo1/sc/qa/unit/data/xlsx/databar.xlsx</text:a>
For me LO fails to open the link, because it resolves the wrong target.
origin: /libreoffice/sc/qa/unit/data/ods/fdo79305.ods
target: /libreoffice/sc/qa/unit/data/ods/xlsx/databar.xlsx
- an ods too much.
The unit test just tests CPPUNIT_ASSERT(aURL.startsWith("..")), which doesn't
make any sense. I would expect a correct absolute URL from LO for the relative
link inside the document, so it can be forwarded to whatever system "open link"
tool is used. Don't know how to test, if the contained link is absolute.
Maybe someone knows where to fix this bug. I really don't want to hide it again
using #ifndef _WIN32, but since this all includes those security link settings
and stuff, I would appreciate if someone else takes a stab at it.
Steps to Reproduce:
1. Open sc/qa/unit/data/ods/fdo79305.ods
2. Ctrl+Click the link
Actual Results:
Error message with wrong path.
Expected Results:
The linked document is opened.
Reproducible: Always
User Profile Reset: No
Additional Info:
Current master. Fails unit test on Windows. Manual test fails for the kde5
backend, but from the URL I guess it's broken on all archs.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>