Created attachment 113682 [details] Sample document - click on any field and mash keyboard, watch chaos ensue To replicate: 1. Create multiple variables. 2. Insert multiple input fields for those variables in close proximity to each other (within 1-3 lines or so). 3. Click on one of the fields and type something in. OR 3. Insert a variable field for one of these variables elsewhere in the document, double-click on that and edit it. Current behavior: Characters at the beginning and end of nearby(?) input fields get deleted, "pushed out" of the input field and turned into regular text, or replaced with "!!br0ken!!", or some combination of the foregoing. Sometimes this starts happening even while inserting the input fields. Expected behavior: Editing one variable should never affect any other variable. Inserting input fields outside of an input field should not affect either old or new input field's variable. Operating System: Windows 7 Professional Version: 4.4.0.3 release Last worked in: 4.1.6 release (possibly 4.3? - definitely did not exist before inline input fields were introduced in any event) Severity marked as "major" as this completely breaks numerous templates I have - I can re-do the template as to get rid of all input fields, but the end effect of that is that I can't use input fields at all.
Reproduced with attachment 113682 [details], but not with v. 4.2.0. Marking as regression. Win 7 Pro 64-bit, LibO Version: 4.4.1.2 Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432 Locale: fi_FI Version: 4.5.0.0.alpha0+ Build ID: 7c0eb12009496a35c927cd5b2520f9c34d50860b TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-03-03_10:52:12 Locale: fi_FI Ubuntu 14.10 64-bit Version: 4.4.1.2 Build ID: 40m0(Build:2) Locale: en_US Version: 4.2.0.4 Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71
Already broken at least in 4.3.5.2.
Was already broken even in 4.2.8
OK, so I'm not sure exactly what is supposed to have been broken since 4.2.8 - if there is anything we'll need more exact reproduction instructions because I can't see it. However, there is a clear bug which was introduced in mid 4.4 master, and that seems to be the one that results in the !!br0ken!! message. To reproduce it, - Load attachment 113682 [details] - Move the cursor right one character (into the first field) - Type "A"s for a while - Undo This specific bug was introduced by the below commit, so let's go with that for now. Adding Cc: to mstahl@redhat.com; Could you possibly take a look at this? Thanks commit cd94a84b89c476760ad74bf088a5d6f8ba4ce209 Author: Oliver-Rainer Wittmann <orw@apache.org> AuthorDate: Fri Jun 13 14:08:22 2014 +0000 Commit: Michael Stahl <mstahl@redhat.com> CommitDate: Fri Jun 13 20:32:14 2014 +0200 125044: - use field's content cache on <SwTxtFld> construction only
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
While I played with the test file on different LO versions, I've seen characters "jumping" out of fields, unability to delete characters, wrong display. But I cannot reproduce it anymore with 5.2.3.3. Everything seems OK.
Created attachment 128967 [details] Screenshot of chaos in 5.2.3 Open document, move one step to the right, hold down the "a" key. Arch Linux 64-bit, KDE Plasma 5 Version: 5.2.3.3 Build ID: 5.2.3-1 CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; Locale: fi-FI (fi_FI.UTF-8); Calc: group Arch Linux 64-bit, KDE Plasma 5 Version: 5.3.0.0.alpha1+ Build ID: 76683829204103446476443b099492c402929004 CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; VCL: kde4; Layout Engine: new; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on November 21st 2016
** 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
Could not reproduce. Used attachment 113682 [details]. Was able to change each input field, where only the other fields with the same variable changed, without affecting the other fields. Also inserted a user field elsewhere and edited its value, which changed in the relevant input fields. Version: 6.3.4.2 (x64) Build ID: 60da17e045e08f1793c57c00ba83cdfce946d0aa CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; Locale: da-DK (en_DK); UI-Language: en-US Calc: threaded (In reply to Matthew Francis from comment #4) > > However, there is a clear bug which was introduced in mid 4.4 master, and > that seems to be the one that results in the !!br0ken!! message. To > reproduce it, > - Load attachment 113682 [details] > - Move the cursor right one character (into the first field) > - Type "A"s for a while > - Undo Could not reproduce. (In reply to Buovjaga from comment #7) > Created attachment 128967 [details] > Screenshot of chaos in 5.2.3 > > Open document, move one step to the right, hold down the "a" key. Why do you think it is chaos? Note that the paragraph style for the first fields are Centered Bold Caps Heading. If you change the style to Default (for example), then the screen will appear differently. Maybe this is now WFM?
Ok, I guess I mistook the normal behaviour for chaos. Indeed, there is no !!br0ken!! or characters turning into regular text. Arch Linux 64-bit Version: 6.5.0.0.alpha0+ Build ID: a7afbbb86d4bb107dfbb24604c46ed9352bcb425 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: kf5; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 7 January 2020