Bug 81720 - After setting a cross-reference object from Fields dialog (or API calls), it can incorrectly receive edit cursor from document canvas during editing corrupting both reference field and document text (STR comment 22)
Summary: After setting a cross-reference object from Fields dialog (or API calls), it ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 64361 123224 126125 (view as bug list)
Depends on:
Blocks: Fields-Cross-Reference
  Show dependency treegraph
 
Reported: 2014-07-24 18:39 UTC by Juang Dse
Modified: 2020-06-05 10:10 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
file with cross-reference (24.34 KB, application/vnd.oasis.opendocument.text-flat-xml)
2014-07-24 18:39 UTC, Juang Dse
Details
test with Win10 + LO 6.3.4 (8.09 KB, application/vnd.oasis.opendocument.text)
2020-01-08 12:56 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Juang Dse 2014-07-24 18:39:52 UTC
Created attachment 103404 [details]
file with cross-reference

1. type 'foo'
2. type Ctrl-a
2. Insert-Crossreference, Set Reference, Name: fooname, Insert, Close
3. type Esc
4. type 'new text'
5. Insert-Crossreference, Insert Reference, Name: fooname, Insert Reference to: Reference

will insert 'foonew text'.

Alternatively, load the attached file foo.fodt and

1. place the cursor at the end
2. type 'n', Ctrl-z

continue from 4.
Comment 1 Juang Dse 2014-07-25 07:38:17 UTC
additionally, the text 'foonew text' is insert not only once but three times.
Comment 2 Joel Madero 2014-07-26 23:04:51 UTC
Confirmed:
Ubuntu 14.04 x64
LibreOffice 3.3 (inherited from OOo) -- updating version (version is oldest confirmed version, not latest)

New - confirmed
Minor - won't prevent high quality and/or professional work but can slow you down
Low - been around for ages, once you know it's happening relatively easy workaround
Comment 3 tommy27 2016-04-16 07:23:57 UTC Comment hidden (obsolete)
Comment 4 Juang Dse 2016-04-18 08:21:23 UTC
bug still there. Now I even get the text

foonew textfoonew textfoonew text

LibreOffice version 5.1.2.2
Linux 3.16.0-38-generic x86_64 GNU/Linux
Comment 5 QA Administrators 2017-05-22 13:24:38 UTC Comment hidden (obsolete)
Comment 6 Juang Dse 2017-05-22 18:02:50 UTC
bug still there.

LibreOffice version 5.3.3 / Linux
Comment 7 QA Administrators 2018-05-27 02:32:36 UTC Comment hidden (obsolete)
Comment 8 Juang Dse 2018-05-28 07:48:21 UTC
bug still there, but modified.

inserting the cross-reference now leads to the text

"foonew textfoonew textfoonew text"

Version: 6.0.4.2
Build ID: 9b0d9b32d5dcda91d2f1a96dc04c645c450872bf
CPU threads: 8; OS: Linux 4.16; UI render: default; VCL: gtk2; 
Locale: en-US (en_US.UTF-8); Calc: group


With the current 6.1 dev version I get

" fooname"
Comment 9 QA Administrators 2019-05-29 02:53:01 UTC Comment hidden (obsolete)
Comment 10 Juang Dse 2019-07-09 07:52:01 UTC
bug still there.

Version: 6.2.5.2
Build ID: 1ec314fa52f458adc18c4f025c545a4e8b22c159
CPU threads: 8; OS: Linux 4.19; UI render: default; VCL: gtk2; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 11 Juang Dse 2019-07-09 08:03:13 UTC
*** Bug 123224 has been marked as a duplicate of this bug. ***
Comment 12 Juang Dse 2019-07-09 08:03:58 UTC
*** Bug 64361 has been marked as a duplicate of this bug. ***
Comment 13 Juang Dse 2019-07-09 08:04:50 UTC
*** Bug 126125 has been marked as a duplicate of this bug. ***
Comment 14 Adomas Venčkauskas 2019-07-09 08:17:55 UTC
Could we bump the importance of this bug to something higher. Bug https://bugs.documentfoundation.org/show_bug.cgi?id=123224 was marked as high by Dieter Praas due to issues this creates for referencing software including Mendeley and Zotero.
Comment 15 Juang Dse 2019-07-10 11:17:16 UTC
(In reply to Adomas Venčkauskas from comment #14)
> Could we bump the importance of this bug to something higher. Bug
> https://bugs.documentfoundation.org/show_bug.cgi?id=123224 was marked as
> high by Dieter Praas due to issues this creates for referencing software
> including Mendeley and Zotero.

I agree. This is a serious issue for all cross-referencing, so the priority should definitely go up.

This not only slows you down (comment 2), but really turns anybody off who tries to switch from other software to LO.
Comment 16 David Lawrence 2019-11-30 20:53:50 UTC
Please make this a priority. An earlier request for work on this mentioned that this bug causes problems with *improving* the way Zotero interacts with LO. However, this bug as it exists now makes the existing Zotero interactions with LO seriously inconvenient. Any edits of my LO Writer document that are too near a Zotero reference will foul the document's reference functions. I found a detailed description of the steps to reproduce this in bug#123224 that was marked as a duplicate of this.

Please understand that this is a serious inconvenience to academic writing that includes citations, references, and a bibliography.
Comment 17 David Lawrence 2019-11-30 20:56:54 UTC
(In reply to Juang Dse from comment #15)
> (In reply to Adomas Venčkauskas from comment #14)
> > Could we bump the importance of this bug to something higher. Bug
> > https://bugs.documentfoundation.org/show_bug.cgi?id=123224 was marked as
> > high by Dieter Praas due to issues this creates for referencing software
> > including Mendeley and Zotero.
> 
> I agree. This is a serious issue for all cross-referencing, so the priority
> should definitely go up.
> 
> This not only slows you down (comment 2), but really turns anybody off who
> tries to switch from other software to LO.

Although marked as a duplicate, the report in 123224 provides a detailed description of the steps to reproduce this problem.
Comment 18 Dan John 2019-12-02 20:53:11 UTC
Hi, I've been dealing with the bug 123224 for a long time with Zotero extension.
It threatens to corrupt my cited documents as I'm working on them as references get mistakenly interfered with and then when Zotero updates its fields it either deletes intended normal text without user easily noticing, or alternately disables automatic updates to field which negates updates from database. Problematic for larger projects like my dissertation which is what I'm using it for :)
I love the Libreoffice and Zotero combination, it would be great if this was fixed for my piece of mind :)

Reproduction instructions / screenshot: https://pasteboard.co/IIGwHe5.png
Comment 19 Juang Dse 2019-12-03 08:53:25 UTC
(In reply to David Lawrence from comment #17)
> Although marked as a duplicate, the report in 123224 provides a detailed
> description of the steps to reproduce this problem.

I agree. But I think this bug here describes the buggy situation somewhat more concise and simpler, as it indeed does not depend on Zotero.

But no surprise, its importance to me comes also from its effect on Zotero. If there is agreement that that is more important, anybody should feel free to reverse the bug dependence.
Comment 20 Adomas Venčkauskas 2019-12-03 09:09:24 UTC
Both bugs describe essentially the same problem. bug#123224 references Zotero for why the bug is important, but the actual steps to reproduce do not require it. Either bug is fine, as long as we get the attention of actual developers (which this bug has unfortunately not seen for over 5 years).
Comment 21 Julien Nabet 2020-01-08 12:56:17 UTC
Created attachment 157003 [details]
test with Win10 + LO 6.3.4

I gave a try to initial comment on Win10 with LO 6.3.4 (last stable LO version)

Is there something wrong in the attached file?
Comment 22 V Stuart Foote 2020-01-08 15:30:42 UTC
Clean STR from dupe bug 123224

Steps to Reproduce:
1. Insert some text in Writer
2. Select a portion of the text -> Insert -> Cross-Reference -> Set Reference, set some text in the "Name" field and click "Insert"
3. Ensure field shading is enabled
4. Place the cursor outside the newly created ReferenceMark, then place it on the edge of the ReferenceMark, type something.

Actual Results:
The ReferenceMark is extended

Expected Results:
The newly typed text remains outside of the ReferenceMark
Comment 23 sdc.blanco 2020-01-08 16:30:46 UTC
(In reply to Julien Nabet from comment #21)
> Is there something wrong in the attached file?
Easy to fix.  

1. Place cursor after foo.  
2. Type anything (e.g., space). (still looks ok)
3. Delete back to edge of (but outside of) ReferenceMark.
4. start typing anything again.  (you should be "rewarded" with an expanding ReferenceMark).

(In reply to V Stuart Foote from comment #22)
> 4. Place the cursor outside the newly created ReferenceMark, then place it
> on the edge of the ReferenceMark, type something.
Only at "end" edge of ReferenceMark.  Can type at beginning of ReferenceMark without problem.

Can repro with:

Version: 6.5.0.0.alpha0+ (x64)
Build ID: 035c7717c135c66c0ec025500b73ae9c13b7c586
CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: GL; VCL: win; 
Locale: da-DK (en_DK); UI-Language: en-US
Calc: threaded

I believe the critical problem here is not just visual.  
The "expanding" field means that the value of the Reference Name is changing (which is why the Zotero users are concerned.)

Have there also been complaints about the fact that one can click inside the ReferenceMark (shaded field) and then type away (i.e., changing the value)?
That would seem like a "cousin" to this problem.  There does not seem like there is a way to protect ReferenceMarks (or variable fields).
Comment 24 Adomas Venčkauskas 2020-01-08 16:59:32 UTC
(In reply to sdc.blanco from comment #23)
> I believe the critical problem here is not just visual.  
> The "expanding" field means that the value of the Reference Name is changing
> (which is why the Zotero users are concerned.)

Correct!

> Have there also been complaints about the fact that one can click inside the
> ReferenceMark (shaded field) and then type away (i.e., changing the value)?
> That would seem like a "cousin" to this problem.  There does not seem like
> there is a way to protect ReferenceMarks (or variable fields).

No, being able to modify ReferenceMarks is actually both desirable and crucial to the functionality of reference managers. However that should not be easy to do accidentally. For reference, Zotero and Mendelay does not have similar problems in Word, where Word fields are used. I.e. you can edit the field text if you deliberately place the cursor inside them, but placing the cursor on either edge of the field does not edit it. The same behaviour in LibreOffice for ReferenceMarks would be ideal.
Comment 25 Xisco Faulí 2020-01-09 14:59:12 UTC
Setting priority to normal. it was set to low in the past, bumping it from low to normal, not from low to high, no reason for that
Comment 26 CRP 2020-05-04 22:15:19 UTC
I have also been experiencing this bug in conjunction with Zotero on MacOS.

It works like this:

1. Insert Zotero citation.
2. Begin typing (all is fine; the field stays intact).
3. Delete what I just typed and type again and this becomes part of the field.

So, the act of deleting up to the edge of the field (but not into it) compromises the edge of the field and subsequent text becomes part of it, causing an error.
Comment 27 Adomas Venčkauskas 2020-06-05 09:49:19 UTC
The bug is still present and highly bothersome for reference manager such as Zotero or Mendeley users, of which there are tens (if not hundreds) of thousands who use LibreOffice. I am certain this is 1 or 2 line change and we just need to get the eyes of the right developers to get it fixed. Could someone who does bug triage reach out to the right people here?
Comment 28 Julien Nabet 2020-06-05 09:56:27 UTC
(In reply to Adomas Venčkauskas from comment #27)
> The bug is still present and highly bothersome for reference manager such as
> Zotero or Mendeley users, of which there are tens (if not hundreds) of
> thousands who use LibreOffice. I am certain this is 1 or 2 line change and
> we just need to get the eyes of the right developers to get it fixed. Could
> someone who does bug triage reach out to the right people here?

Since you seem confident about the fact it would just need a 1 or 2 lines change in the code, I propose you to give it a try.
Here's a start link to start contributing in dev part:
https://wiki.documentfoundation.org/Development/GetInvolved
(some devs may help you if necessary on forum or IRC)
Comment 29 Adomas Venčkauskas 2020-06-05 10:04:20 UTC
(In reply to Julien Nabet from comment #28)
> (In reply to Adomas Venčkauskas from comment #27)
> > The bug is still present and highly bothersome for reference manager such as
> > Zotero or Mendeley users, of which there are tens (if not hundreds) of
> > thousands who use LibreOffice. I am certain this is 1 or 2 line change and
> > we just need to get the eyes of the right developers to get it fixed. Could
> > someone who does bug triage reach out to the right people here?
> 
> Since you seem confident about the fact it would just need a 1 or 2 lines
> change in the code, I propose you to give it a try.
> Here's a start link to start contributing in dev part:
> https://wiki.documentfoundation.org/Development/GetInvolved
> (some devs may help you if necessary on forum or IRC)

While I appreciate the idea, a 1 or 2 line fix for someone who is involved with the codebase, works on it every day and knows the code inside out takes anywhere from 15 minutes to an hour to make. For someone who does not have the build and development environment setup and has never looked at the codebase it could mean days or weeks, and also possibly hours wasted of those same developers, providing help via IRC and mailing lists on how to set this whole thing up and figure out where the code related to the features is. While this is an important issue for Zotero, it is just an important for Document Foundation if they are at all trying to be a serious alternative to Microsoft Word, where this works as expected.

Having said that, getting the attention of the right developers for this would be the most time efficient course of action and provide a huge improvement in usability for a large and passionate chunk of LibreOffice's userbase, who otherwise get edged to Word exactly for such minor annoyances.
Comment 30 Julien Nabet 2020-06-05 10:10:21 UTC
(In reply to Adomas Venčkauskas from comment #29)
> ...
> Having said that, getting the attention of the right developers for this
> would be the most time efficient course of action and provide a huge
> improvement in usability for a large and passionate chunk of LibreOffice's
> userbase, who otherwise get edged to Word exactly for such minor annoyances.

Just consider the number of existing bugs declared on Bugzilla + priorities and compare with few devs (knowing that some work now for Collabora and so are more focused into their specific features sold by this company, like online collaboration), you'll understand why it's not fixed yet.
So yes, for a first bug, it may take time for you but once it'll be done, you may be able to tackle other bugs far more quickly since build/debug env will be already installed! :-)