Summary: | 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) | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Juang Dse <juangdse> |
Component: | Writer | Assignee: | Matti Tyrväinen <matty> |
Status: | REOPENED --- | ||
Severity: | normal | CC: | adomas.ven, jmadero.dev, juangdse, matty, nalimilan, pterion, robert, sdc.blanco, stephane.guillou, vsfoote, xiscofauli |
Priority: | medium | ||
Version: | Inherited From OOo | ||
Hardware: | All | ||
OS: | All | ||
URL: | https://ask.libreoffice.org/t/cannot-exit-the-cross-reference/45964/2 | ||
See Also: |
https://bugs.documentfoundation.org/show_bug.cgi?id=155418 https://bugs.documentfoundation.org/show_bug.cgi?id=157287 |
||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 107905 | ||
Attachments: |
file with cross-reference
test with Win10 + LO 6.3.4 |
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 ** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.5 or 5.1.2 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT - Update the version field - Reply via email (please reply directly on the bug tracker) - Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16 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 ** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.2.7 or 5.3.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170522 bug still there. LibreOffice version 5.3.3 / Linux ** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug 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" Dear Juang Dse, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug 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. (In reply to Adomas Venčkauskas from comment #29) > 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. ... > > Having said that, getting the attention of the right developers for this > would be the most time efficient course of action See how right was Julien, telling that it's reasonable to try yourself! It was Matti, a user who decided to fix what bothered them, got their hands dirty in code, and fixed this finally. Thank you Mati! Not really sure what your point is, Mike. I never said it was impossible for me to fix this, merely that it was time-inefficient. I'm thrilled Matti went through the trouble to do this, but I believe my point is exactly proven both in the fact that it was a two-line fix, and that it took someone without prior experience a long back-and-forth with core developers to fix it. My point was, that no matter what you imagine, there is no point telling others what to do. E.g., telling "developers should do it, because they would do it faster". Because developers in a FLOSS project do what *they* need. And users insisting in that could be right *in theory*, except for the reality check. If a user *is able* to fix, and *wants* it fixed, then not doing it solely because others could do it faster is a fallacy. I really don't know why you feel the need to have a *gotcha* argument under a bug ticket here, or to strawman things I said. I didn't "tell" anyone to do anything. I asked if someone could get the attention of developers so that this could get addressed faster. If you want to continue lecturing me on the topic of FLOSS development, you should probably know that I am a developer in a FLOSS project myself, and that we value it very highly when people bring attention to issues that affect thousands of our users and that are easily fixed with the right knowledge, i.e. low-hanging fruit. Just like all FLOSS projects, we encourage people to contribute, but we don't belittle them if they decide that fixing a given problem is not possible to them due to lack of time or knowledge. I hope that LibreOffice contributors and Document Foundation leaders can work in the same spirit. Reopening as this was reverted in 24.2 for bug 157287: https://gerrit.libreoffice.org/c/core/+/158059 |
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.