Bug 119700 - Links to external HTML files updated wrong
Summary: Links to external HTML files updated wrong
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.3.0.3 release
Hardware: All All
: medium normal
Assignee: Eike Rathke
URL:
Whiteboard: target:6.2.0 target:6.1.4
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2018-09-04 18:43 UTC by NoRa
Modified: 2018-12-09 09:31 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
example for the bug (12.83 KB, application/vnd.oasis.opendocument.spreadsheet)
2018-09-04 18:44 UTC, NoRa
Details
File from scratch with external link after 3 times save/load (9.50 KB, application/vnd.oasis.opendocument.spreadsheet)
2018-09-11 12:31 UTC, NoRa
Details

Note You need to log in before you can comment on or make changes to this bug.
Description NoRa 2018-09-04 18:43:02 UTC
Description:
If you have a file with links to an external HTML-file it will be updated wrong.

In the attachment is a file with links to Quotes of Aurelius and Amazon.
In the sheet Stoxx ar the link to the sheet Quotes where the external link is set.
After loading and NOT updating everything is good. 
After updating the external links the formular in the sheet Stoxx for Aamzon is changed and in the sheet Quotes the old data of the external link is moved down and the updated data is set to the correct place. BUT the formula for Amazon-Quote in Stoxx D4 is chenged to the old data and not to the updated.

I think it's since version 5.3.?? and exept in 6.1.0 also in 6.1.1dev


Steps to Reproduce:
1. Load the file Stoxx.ods
2. Look at the sheet Stoxx for D4, change to Quotes and look
3. Update the external links

Actual Results:
the old data for Amazon quotes is moved down at the old place are the updated data.
the formular in Stoxx:D4 is changed to the place of the old data

Expected Results:
the old data should be overwritten and not be moved down
the formular should not be changed


Reproducible: Always


User Profile Reset: No



Additional Info:
Comment 1 NoRa 2018-09-04 18:44:58 UTC
Created attachment 144674 [details]
example for the bug
Comment 2 Regis Perdreau 2018-09-05 07:35:46 UTC
Confirmed !

Version: 6.0.3.2
Build ID: 1:6.0.3-0ubuntu1
Threads CPU : 4; OS : Linux 4.15; UI Render : par défaut; VCL: x11; 
Locale : fr-FR (fr_FR.UTF-8); Calc: group
Comment 3 NoRa 2018-09-05 10:00:43 UTC
Hi,

save the file after the update and reload it. Then this will continue.
Old data areas will be moved down and the formula will continue to change.

This is not the case with the single-line area in the example Aurubus.
Comment 4 NoRa 2018-09-06 18:50:00 UTC
Hi,

the bug is similar to bug 117533. i think that this bug is already critical, because the formula still shows the old data after an update. a productive work is not possible with it.
Comment 5 NoRa 2018-09-06 18:52:50 UTC
Sorry, i mean bug 117563
Comment 6 Xisco Faulí 2018-09-10 16:07:38 UTC
I can also reproduce it in

Version: 5.2.0.0.alpha0+
Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53
Threads 4; Ver: 4.10; Render: default; 

Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4

> 
> I think it's since version 5.3.?? and exept in 6.1.0 also in 6.1.1dev

Do you remember the specific version?
Comment 7 Xisco Faulí 2018-09-10 16:19:23 UTC
This seems pretty similar to bug 106074.
Do you reproduce the problem if the document is created from scratch ?
Comment 8 NoRa 2018-09-10 18:24:01 UTC
No, I don't build Libreoffice from scratch.

i use the fresh package from manjaro-linux or for 6.1.1dev a customized package from the build server of the document foundation.
Comment 9 NoRa 2018-09-10 18:45:14 UTC
>
> Do you remember the specific version?

I think but i'm not very sure it was the first time in the 5.3 version. And then in every version after it.
Comment 10 Xisco Faulí 2018-09-10 20:05:25 UTC
I don't mean building LibreOffice from scratch.
What I mean is if you reproduce the problem if you create the file from scratch ?
Comment 11 NoRa 2018-09-11 12:31:48 UTC
Created attachment 144790 [details]
File from scratch with external link after 3 times save/load

Here is a fresh file created under Win8.1 with lO 6.1.1 from the build server.

This file was 3 times saved, loaded and refresh the link.
Comment 12 NoRa 2018-09-11 16:55:08 UTC
I've tested this file with the version 5.2.7.2 portable. There the bug did not occur.
Comment 13 NoRa 2018-09-25 18:47:06 UTC
I'm sorry for asking, but is there a solution to this problem?

The links update, but are not displayed because of the formula change.

So working with it is pointless.
Comment 14 m_a_riosv 2018-10-05 21:15:21 UTC
I can't find now but I remember this issue happening with data ranges (menu/data/define ranges)
Comment 15 Xisco Faulí 2018-10-17 16:39:33 UTC
(In reply to NoRa from comment #12)
> I've tested this file with the version 5.2.7.2 portable. There the bug did
> not occur.

adding regression and bibisectRequest
Comment 16 Eike Rathke 2018-11-14 14:39:18 UTC
Taking.
Comment 17 Eike Rathke 2018-11-14 14:52:41 UTC
Regression from
https://gerrit.libreoffice.org/plugins/gitiles/core/+/f6e6a6139e90d6e88fb65308e8592193ac602a8a%5E!/
that saves table:last-row-spanned of the linked range wrongly.
Comment 18 Xisco Faulí 2018-11-14 14:54:10 UTC
setting the keyword correctly...
Comment 19 Commit Notification 2018-11-14 17:28:31 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/6e566c2b2b23d457a9fd47c16df15ce11e84c8e8%5E%21

Resolves: tdf#119700 save correct table:last-row-spanned

It will be available in 6.2.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.
Comment 20 Eike Rathke 2018-11-14 17:33:23 UTC
Note that the source row count value was wrongly saved to file, this can't be fixed when loading the document. For affected documents the linked external needs to be updated once, the target range maybe cleaned up after that, and the document saved again. After that, identical source table sizes will result in the desired behaviour again.
Comment 21 Eike Rathke 2018-11-14 17:34:45 UTC
Pending review https://gerrit.libreoffice.org/63382 for 6-1
Comment 22 NoRa 2018-11-16 17:42:39 UTC
Great, thanks, Good Job
Comment 23 Commit Notification 2018-11-17 16:50:49 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-6-1":

https://git.libreoffice.org/core/+/f2c6156a90093d38e1ab304d11ffed90555d5fa1%5E%21

Resolves: tdf#119700 save correct table:last-row-spanned

It will be available in 6.1.4.

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.
Comment 24 NoRa 2018-12-09 09:31:36 UTC
Great,
I've tested in 6.1.4-1 and everything works fine.