I just installed 3.3 and noticed on my first transaction (which was pre-filled with auto-text from a previous similar transaction for the same payee) that arrow keys no longer work as expected when editing this auto-filled text. When tabbing through the transaction (tested in Note, then Memo) the full text for that cell is selected as before, but hitting the right-arrow key to append additional text, or get to the end of the line to backup and change only some of the text is not possible. Hitting the right-arrow changes the selection to the second 'word' (including leading and trailing spaces) in the line and no subsequent use of the arrow keys (or TAB) works to cycle through the 'sentence' or advance or retreat in anyway. The arrow keys (left and right) are non-responsive at that point. (up and down work similar to TAB to move between cells) Editing is still possible though. Note, if you are entering new text in a transaction and then go back to that cell to edit it, the arrows work as expected. Additionally, cells belonging to pre-filled splits work as expected after you enter a new split in the transaction. This appears to just be an issue on pre-filled cells, before entering a new split. (if one even needs to be entered, which isn't always the case)
I can replicate this.
There are other weird issues that could be related. If I double-click a word to select it and then press the shift key, the text selected changes. The same happens if I press the ctrl, delete, backspace or arrow keys. If instead I start typing new text to replace the selected text, a different part of the text, other than that selected, is replaced. This only happens on a new auto-filled transaction. This was working correctly in 3.2.r48.gc444729db but not in 3.2.r304.g40bcd1e37.
I too am seeing the issue with the shift key, but this time it selects every part of the memo except the first word. It also locked up in the debit column once I tabbed into it to change the amount, the cents were highlighted and I could not use the arrows to change the selection or deselect anything. I had to click out of the field and back into it in order to edit what I wanted.
I just tried to edit an auto-filled note. Trying to work around the selection of everything but the first word, I selected a single word I wanted to change and started typing the replacement. Without the highlight first changing to reselect all but the first word (which I typed manually that prompted the auto-fill) my replacement text started after the first word replacing everything else. The effect is that rather than simply replacing the one highlighted word, all of the auto-fill text was discarded and my typing continued as if it had never existed. I seem to recall a similar bug report for an earlier 3.x release on this issue, not sure if it is a regression, or the two are related.
I think you're thinking of bug 796734; there's also bug 796665. The fundamental issues are the interactions with input modules, and disabling input modules worked as a work-around for bug 796734 so it might do for this as well.
Just to clarify, I'm running on Arch Linux with KDE.
Renaming /usr/lib/gtk-3.0/3.0.0/immodules.cache made no difference to this issue on my Arch system.
Same issues under Debian/unstable with the gnucash 1:3.3-1 Debian package.
(In reply to Richard Ullger from comment #2) > There are other weird issues that could be related. > > If I double-click a word to select it and then press the shift key, the text > selected changes. The same happens if I press the ctrl, delete, backspace or > arrow keys. If instead I start typing new text to replace the selected text, > a different part of the text, other than that selected, is replaced. > > This only happens on a new auto-filled transaction. I get something similar, but with the empty transaction line, as the full date is selected by default. I had reported bug 796888 about that; this occurred several times, but I don't know how to reproduce it.
(In reply to Vincent Lefevre from comment #9) > I get something similar, but with the empty transaction line, as the full > date is selected by default. I had reported bug 796888 about that; this > occurred several times, but I don't know how to reproduce it. The only time I have any issues with the date field is once the transaction has been auto-filled and I go back to the date field. When starting a new transaction, I do not have these issues with the date field.
*** Bug 796908 has been marked as a duplicate of this bug. ***
(In reply to John Ralls from comment #5) > I think you're thinking of bug 796734; there's also bug 796665. The > fundamental issues are the interactions with input modules, and disabling > input modules worked as a work-around for bug 796734 so it might do for this > as well. I did have Unicode Hex Input enabled on my system. Removing it and renaming the immodules.cache file had no effect.
*** Bug 796912 has been marked as a duplicate of this bug. ***
*** Bug 796888 has been marked as a duplicate of this bug. ***
*** Bug 796913 has been marked as a duplicate of this bug. ***
*** Bug 796918 has been marked as a duplicate of this bug. ***
Note that this bug is new in GnuCash 3.3; I just built and installed 3.3 and 3.2 from scratch and the bug happens in 3.3 and not in 3.2.
*** Bug 796920 has been marked as a duplicate of this bug. ***
I've found two ways to deal with this. Both are so awkward they are more of a kludge and not even a workaround. 1. If a space is inserted at the end of an auto-filled value then the bugs go away. 2. Similarly, the SHIFT issue can be avoided by clicking the end of the field (because the END button is broken, and because Backspace won't remove the damn highlight) and only then pressing the Backspace key to remove a character. I can then proceed with highlighting and typing a proper noun.
*** Bug 796928 has been marked as a duplicate of this bug. ***
This has been fixed in git and will be included in GnuCash 3.4.
This is not completely fixed yet. I will open a separate bug for 3.4.
FYI, I also got the same issue with 3.2 (I was still using this version due to this bug, thinking that it had been introduced in 3.3), but only once.
