Mint 18.3 with MATE. Gnucash compiled from tarball. Attempt to enter a transaction by duplicating an earlier transaction. This succeeds with focus in the Description field in new transaction but the field is not editable. Moving to another field and then returning overcomes the problem.
The problem continues in 3.5. Note that neither tab nor enter will move off the description. Mouse click on another field works.
It works correctly for me on MacOS 10.14, Windows 10, and Debian stable, meaning that I can edit the Description field in the new txn without having to move to another field and back and that Tab and Enter work as expected.
Testing with version 3.6 yields two observations: 1. The problem only seems to occur when duplicating a transaction with splits. 2. If gnucash is started, the first duplication of a split transaction does not show the bug. The next duplication of any split transaction does.
There's no such thing as a transaction without splits. Do you mean a transaction with more than two?
On Jul 3, 2019, at 6:53 PM, Dale Alspach <alspachde@gmail.com> wrote: > There is no reason to be insulting. You surely know very well what I meant and that > there was an endless discussion on the Gnucash users list of what posters mean by > transactions with splits. Do not email developers directly unless *explicitly requested to do so*. If you're insulted by a non-personal statement of fact and request for clarification you have very thin skin indeed. I'll take your reply as "sorry, yes, transactions with three or more splits". To which I have a further question: Did you test exactly three splits, and if not how many? Is this in "basic" view with the splits hidden? Do you have "Use split-action field for number" in File>Properties, Accounts tab checked? What, if anything, are you adjusting in the little dialog box that comes up before the new transaction is created? (I've been changing the date.) In comment 1 you say that the tab and enter keys don't leave the Description field. Is the description text selected? What happens if you mouse-click in the Description field? What versions of gtk and glib are installed? (The easiest way to get that is from the command line, `pkg-config --modversion gtk+-3.0 glib-2.0`).
Preferences Default Style is Basic ledger. No other items are selected under Register Defaults Register Actions: Enter moves to blank transaction and Auto-raise lists are selected. Properties; Use Split Action Field for Number is not selected. One test transaction was a loan payment with three lines: principal, interest and payment. Duplicate was selected from the bank account register. Another test had 4 lines. It does not seem to matter whether the date is changed or not in the pop-up box. Once the new transaction appears, the cursor is at the end of the text in the description field. Clicking into the white space following the text or the text has no effect except to move the cursor. Today when testing the text was not highlighted but I recall in the past that sometimes it was. In that case clicking in the description field removed the highlighting but did not resolve the keyboard input problem. Note that typically I choose the transaction to be duplicated by clicking the description field. I tried selecting the transaction by clicking the date field. The result was that the cursor was frozen in the date field of the new transaction. It appears that closing and reopening a register will also allow duplicate to work correctly at least once. >pkg-config --modversion gtk+-3.0 glib-2.0 3.18.9 2.48.2 I tried double line mode and separately auto-split mode and the problem remained. The behavior seems to be difficult to pin down.
I tried some more with Ubuntu 16.04 which has the same gtk and glib versions. No luck, I was able to duplicate several 3-split transactions in succession. As long as the description field had focus in the source transaction it had focus in the destination transaction, with the field's contents highlighted so that when I begin typing the whole thing is replaced by what I type. No focus issues at all. The only variation on that is if I click the left side of the transfer account field so that no field has keyboard focus. Duplicating that creates a new transaction in which no field has keyboard focus, but clicking in the description field immediately focusses there and I can type a new description. I should have asked before if there are any warnings in the tracefile (https://wiki.gnucash.org/wiki/Tracefile); if there aren't, try running gnucash with --log gnc.register=debug. Maybe there will be a clue there. If you decide to attach the resulting tracefile check first to make sure that there isn't anything in it you might consider confidential as some debug strings print the data being processed.
Created attachment 373313 [details] Trace File This trace contains the first few moments of use of gnucash 3.6. Some schedule transactions were executed, followed by two duplicates of transactions in different registers both of which produced the bug.
Comment on attachment 373313 [details] Trace File Looks like you have some custom scheme left over from Gnucash 2.6. You need to rewrite it, I suggest that you rename config.user until you've done so. It would be useful to know if those WIDGET_REALIZED_FOR_EVENT failures have anything to do with the problem. I think the easiest way to tell is to run `gnucash --logto=stderr` and watch the terminal for those errors as you do a duplication and attempt to edit the description field.
Lines such as ERROR <Gtk> gtk_widget_event: assertion 'WIDGET_REALIZED_FOR_EVENT (widget, event)' failed seem to be generated by trying to use enter or tab to leave the field not by the creation of the bug. There is an oddity to the duplicate generated transaction whether or not the bug is present. The new transaction appears with the Description field text highlighted but the notification line at the bottom of the register is not showing the text. Instead the current default date is showing. Clicking in the description field does not change the notification line but editing (backspace over the last character) causes the notification line to start displaying the text. This suggests that the duplicate process has not brought the new transaction to the same state as a manually created transaction which is ready to be committed. Sometimes when the bug is present I have seen notification lines with the wrong message, e.g., the cursor is in the Description field but the message is for a blank Num field. I tested version 3.5 on a laptop with linux mint 19.1. The bug was harder to produce (more successful duplicates before occurrence) but did occur.
I am unable to reproduce on version 4.2 so closing. If there is still a problem, please raise a new bug against the current version and give as much information as possible, thank you.
