additionally, the text 'foonew text' is insert not only once but three times.

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

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

bug still there.

LibreOffice version 5.3.3 / Linux

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"

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

*** Bug 123224 has been marked as a duplicate of this bug. ***

*** Bug 64361 has been marked as a duplicate of this bug. ***

*** Bug 126125 has been marked as a duplicate of this bug. ***

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.

(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.

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.

(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.

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

(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.

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).

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?

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

(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).

(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.

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

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.

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?

(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)

(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.

(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! :-)

This bug is still effecting me on the LO packaged by the linux distro I use for academic writing with zotero, and from threads on the zotero forum I see it is effecting others as well. This adds a considerable inconvenience for using the software for professional purposes despite some workarounds.

The difficulty and time required to fix it have been made clear earlier in the thread, nevertheless I thought I would comment to confirm that this is still effecting LO users using reference managers for professional writing.

Can we fix this? I have this bug with Zotero and it is very frustrating.

see: https://forums.zotero.org/discussion/94871/cannot-leave-citation-field-in-libreoffice-writer

It is difficult to believe that this bug remains unresolved for such a long time, since 2016! This is a constant irritation to anyone who used LO professionally and academically, greatly affecting the workflow and breaking the creative writing process. 

Here is a report from LO community: https://ask.libreoffice.org/t/cannot-exit-the-cross-reference/45964/2

*** Bug 153085 has been marked as a duplicate of this bug. ***

Still present on LO 7.5. As noted above, it hampers usage enough to steer users from LO to Word et al. 

Another workaround is to use the insert mode (via the "Insert" key on the keyboard) to prevent the cursor from entering the ReferenceMark in the first place. This doesn't work if the ReferenceMark is at the very end of a paragraph, but can be helpful elsewhere.

I've requested a code review for making Reference Marks behave like "nested attributes" eg. Hyperlinks (ie. as described by Adomas Venčkauskas).

https://gerrit.libreoffice.org/c/core/+/146941

Thank you so much for the patch Matti! Hoping it gets accepted quickly, seems like the review process is moving along!

I'm reverting the status to NEW in the hope that someone else will pick it up as I'm currently unable to move forward with the patch in a timely manner. The proposed patch *should* be enough to fix the issue, but, as it makes the existing tests fail in an unexpected way, I can not recommend using it as-is to avoid possible document-corrupting side-effects.

Picking this up once more as I have some time to throw at it again. Patchset 7 solves the failing test, just need to iron out some small kinks like the whole program crashing when trying to reproduce the original bug ;)

Patchset 8 shouldn't crash. Here's how the original bug fares:

1. type 'foo', then press Ctrl-a
2. Insert - Cross-reference, Set Reference, Name: fooname, Insert, Close

At this point the document has the text "foo" followed by the cross-reference "foo" ("foofoo"), with the cursor between the "foo"s. No text is selected, so pressing Esc does nothing.

3. type Esc
4. type 'new text'

Now the document says "Foonew textfoo". Without the patch it'd say "Foonew text" and all of the text would be inside the reference.

5. Insert - Cross-reference, Insert Reference, Name: fooname, Refer using: Referenced text

will insert "foo", resulting in the text "Foonew textfoofoo" (or the fully-correct "Foonew textFoo" when using the attached foo.fodt).

I'd call that progress over the pre-patch "Foonew textFoonew text" which would keep expanding AND re-inserting the text, eg. becoming "FoonewtextFoonew textFoonew text " after pressing space once.

As evident by the title of my patch, it fixes reference marks' expanding. I will test that Zotero cross-references update correctly, but I will not be fixing "foofoo" at step 2 in the immediate future. Imo it should be considered to be a new, less disruptive, separate bug.

I can confirm that with Patchset 8, Zotero citations no longer expand, but do update as before. I'll be using the patch in "production" going forward, hopefully it'll be accepted (as-is) soon!

Matti Tyrväinen committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/384a80fc56e75e3d1ee18ffc303db85490716829

tdf#81720 Don't expand Reference Marks

It will be available in 7.6.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.