Bug 131425 - Inconsistent behavior when changing part of a cross reference source
Summary: Inconsistent behavior when changing part of a cross reference source
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.0 release
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Fields-Cross-Reference
  Show dependency treegraph
 
Reported: 2020-03-19 13:53 UTC by Christian Pietzsch
Modified: 2024-10-15 06:41 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Test file (8.66 KB, application/vnd.oasis.opendocument.text)
2020-03-19 13:54 UTC, Christian Pietzsch
Details
Scenario 3 (10.98 KB, image/png)
2020-03-19 13:55 UTC, Christian Pietzsch
Details
Scenario 1 (11.55 KB, image/png)
2020-03-19 13:55 UTC, Christian Pietzsch
Details
Scenario 2 (22.95 KB, image/png)
2020-03-19 13:56 UTC, Christian Pietzsch
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Pietzsch 2020-03-19 13:53:42 UTC
Description:
Marking/overwriting part of a cross reference leads to different beahaviors depending on whether the reference has been edited before since the document was opened.

Ref 1 has a leading space included in the ref source
Ref 2 has no spaces
Ref 3 has a space following the text included in the source

Steps to Reproduce:
1st scenario:
1.Open attached file (or create new file --> type a word --> set reference [Insert - Field - More Fields - Cross-references])
2. doubble click on first Ref* to mark the word
3. type new word

2nd scenario:
1. open document
2. klick inside Ref* and delete a character or add one
3. double click to markt the word
4. type to replace with new word

3rd scenario:
1. open document
2. put cursor at the end of one of the Ref*
3. use backspace to delete the word
4. Type new word

Actual Results:
1st scenario: (see attachment [Refs double click no edit])
- Ref1 --> first letter of the new word gets included into the cross ref; the rest doesn't 
- Ref2 --> cross ref get destroyed
- Ref3 --> none of the new characters get included into the cross ref

2nd scenario: (see attachment [Refs with editing])
- Ref1 --> new word completely in cross ref (desired behavior!!)
- Ref2 --> cross ref annihilated
- Ref3 --> none of the new characters get included into the cross ref

3rd scenario:(see attachment[Refs backspace no edit])
-Ref1 --> none of the newly typed characters get included in the cross ref (only leading space persists)
- Ref2 --> cross ref destroyed (expected behavior!!)
- Ref3 --> none of the new characters get included into the cross ref



Expected Results:
When double clicking a referenced word (no matter if it has a leadind/following or no space) and retyping should always keep the reference alive and replace it with the new word (see Ref1 in 2nd scenario).
In my opinion the same should apply for deleting part of a referenced section (section deleted is at the end or beginning of the marked section--> deleting things in the middle doesn't cause problems)
Only exception is deleting the whole referenced section/word (like Ref2 in 3rd scenario)


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 6.4.1.2 (x64)
Build-ID: 4d224e95b98b138af42a64d84056446d09082932
CPU-Threads: 2; BS: Windows 10.0 Build 18362; UI-Render: GL; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: threaded
Comment 1 Christian Pietzsch 2020-03-19 13:54:10 UTC
Created attachment 158811 [details]
Test file
Comment 2 Christian Pietzsch 2020-03-19 13:55:00 UTC
Created attachment 158812 [details]
Scenario 3
Comment 3 Christian Pietzsch 2020-03-19 13:55:27 UTC
Created attachment 158813 [details]
Scenario 1
Comment 4 Christian Pietzsch 2020-03-19 13:56:07 UTC
Created attachment 158814 [details]
Scenario 2
Comment 5 Dieter 2020-05-15 12:57:09 UTC
I can confirm all observations with

Version: 7.0.0.0.alpha1+ (x64)
Build ID: 99c337d1d3831ce9d2c7dc1cbff713f4ac49d6ac
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win; 
Locale: en-GB (de_DE); UI: en-GB
Calc: CL

=> NEW

But I'm not sure, what the expected behaviour should be. Let's ask Design-Team for further input here.
Comment 6 Heiko Tietze 2020-05-19 04:52:54 UTC
Modifying cross-references is supposed to be done per Edit > Fields dialog, see [1]. Fields are variables and I don't see need for direct editing and would block it. Unfortunately Edit > Field is disabled for some reason. Any idea, Cor?

[1] https://help.libreoffice.org/6.4/en-US/text/swriter/guide/references_modify.html
Comment 7 Christian Pietzsch 2020-05-19 14:01:35 UTC
(In reply to Heiko Tietze from comment #6)
> Modifying cross-references is supposed to be done per Edit > Fields dialog,
> see [1]. Fields are variables and I don't see need for direct editing and
> would block it. Unfortunately Edit > Field is disabled for some reason. Any
> idea, Cor?
> 
> [1]
> https://help.libreoffice.org/6.4/en-US/text/swriter/guide/references_modify.
> html

I think you misunderstood my intention. I didn't wanna edit the fields inserted based on the cross reference. What I wanted to do is edit the original referenced text, so that it changes all the fields based on it.
What edit fields does, is that it lets you change an inserted field (text based on reference for example). It works but only is enable if you click in front of the field (not the original text that is referenced)
Comment 8 Cor Nouws 2020-05-20 19:59:23 UTC
Interesting one :)

So is my conclusion right, that as soon as the selection touches the limit of the defined reference field, that the reference is not extended if the text is changed?

I'm tempted to suggest to look at how it works with text that has formatting as bold, italic.
I would expect the same behavior in this case.
Comment 9 Heiko Tietze 2022-02-01 10:49:17 UTC
Mike, can you shed some light on this issue?
Comment 10 Mike Kaganski 2022-02-01 11:02:36 UTC
(In reply to Heiko Tietze from comment #9)

No I can't; looks erratic.
Comment 11 Heiko Tietze 2022-02-01 11:12:43 UTC
Erratic behavior is a bug. Cannot help from UX POV unless to support the expectation.
Comment 12 Buovjaga 2024-09-19 09:24:28 UTC
Still repro, already in 3.5 (at least with attachment 158811 [details]).

Arch Linux 64-bit
Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: d500848976b6244048684a9972322b582559910a
CPU threads: 8; OS: Linux 6.10; UI render: default; VCL: kf6 (cairo+wayland)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: CL threaded
Built on 19 September 2024
Comment 13 Christian Pietzsch 2024-10-15 06:41:44 UTC
(In reply to Buovjaga from comment #12)
> Still repro, already in 3.5 (at least with attachment 158811 [details]).
> 
> Arch Linux 64-bit
> Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
> Build ID: d500848976b6244048684a9972322b582559910a
> CPU threads: 8; OS: Linux 6.10; UI render: default; VCL: kf6 (cairo+wayland)
> Locale: fi-FI (fi_FI.UTF-8); UI: en-US
> Calc: CL threaded
> Built on 19 September 2024

I also just gave it a try and the only change I found was that in scenario 3 for the first ref, all the new characters are part of the ref. Therefore deleting the text with backspace and writing a new text keeps it in the ref