Confirmed bug in v.3.5.

Looks like the old shift key bug has fully returned in 3.5-126:

1. Autofill a transaction Description.
1. Click in the middle of the text to place the cursor.
2. Click and drag from the middle of the text to the right end.
3. Press the Shift key.

As soon as the Shift key is touched, the selection changes.

Increasing severity to Major because this is a significant impediment to data entry.

I can't reproduce this on Win10 using either GnuCash-3.5 or GnuCash-3.5-2019-05-01-git-3.5-136-gbfbb89f6e. Are you using an older version of Windows?

Repeated problem using 3.5-223 on Windows 10.

1. Copy some text.
2. Click on the Description column for a new transaction.
4. Press Ctrl+V OR Select Paste from the Edit menu.
5. Highlight any part of the pasted text.
6. Press either Shift key.

Repeated problem using 3.5-223 on Windows 10.

1. Autofill a transaction Description.
2. Click in the middle of the text to place the cursor.
3. Click and drag from the middle of the text to the right end.
4. Press the Shift key.

I understood from your original report how to reproduce the problem. You reported there that it happened on GnuCash 3.4 and in subsequent comments that it occurs in later versions as well, meaning that the version of GnuCash isn't material.

It does make sense that if it erases one selection it would erase all selections. For the same reason the problem doesn't happen for me with either of your new scenarios.

Might it be a localization issue? Are you using an input method? How about hardware? Have you tried with a different keyboard?

I can also repeat this on Windows 2012 over RDP with no keyboard.  So it does not seem to be specific to hardware or OS version.

I can try my laptop too if that would help.

Really? How do you type a Shift key with no keyboard? 

I trust you mean Windows Server 2012 as there's no such thing as Windows 2012, and that you really used the same keyboard on your Win10 desktop. 

Reproducing or not on your laptop would rule out or support the bad hardware hypotheses.

What about Language and Region settings?

No, I did not use a desktop keyboard.  You asked me to check hardware and keyboard involvement, so I switched to testing a headless server with a mobile client.  In this case the Shift key is emulated by the client app, and the test result is the same.

OK.

Does the behavior manifest with the control, alt, and/or windows keys?

Yes, as well as Caps Lock, Num Lock, Backspace, Delete, Insert, Break, and Esc.

Just tested Windows 10 on my laptop.  Same results.

All of these machines are using English (United States)

Backspace, Delete, and Escape along with any actual character are expected to delete the selection. I guess that since break isn't a modifier key that it would also be expected. capslock, numlock, and the ones I listed shouldn't affect the selection on their own... and they don't on my VM. So we need to figure out why they're different on your machines.

Do you think you can set up a debug environment? https://wiki.gnucash.org/wiki/Stack_Trace#Windows has some instructions, but it's not trivial on Windows.

I have no experience with those specific debuggers and not enough free time to dig into it in the near future.

Additional bug without using the Shift key:

1. Autofill the transaction Description.
2. Double click one of the autofilled words to highlight it.
3. Press the Backspace key.

Backspace works, however the highlight is not cleared, so any further input has unexpected results.

Also:

1. Autofill the transaction Description.
2. Click at the end of the Description to set the cursor at end.
3. Press the Backspace key.

Backspace works, however a highlight is created similar to the one present at step 1 above, even though the highlight had been removed in step 2.

Could not find the same problem by using the End key.

Bugs confirmed in v3.6.

I might have an hour or so this week to work on this.  If I can get gdb installed, what exactly do you need?  You want me to type something with the Shift or Backspace and then try to grab a stack trace while the wrong text is highlighted?

No, that wouldn't work.

Let's start by setting some breakpoints to get a rough idea of where the selection is disappearing. Set up your desktop so that the terminal and GnuCash windows are side-by-side.

Set a breakpoint on the master keypress handler
  b gnucash_sheet_key_press_event
and start GnuCash
  r
Using the mouse only do the procedure in your original report. When the debugger stops at the breakpoint set some more breakpoints:
  b gnucash_sheet_key_press_event_internal
  b gnucash_sheet_clipboard_event
  b gnc_table_traverse_update
  b gnucash_sheet_cursor_move
then continue:
  c

At each breakpoint observe whether the selected text has been removed. If it hasn't yet, tell gdb
  fin
and check again. If it's still there, tell gdb to continue. You won't have the symbols to do line-by-line debugging but you can sort-of follow along by looking at https://github.com/Gnucash/gnucash/blob/maint/gnucash/register/register-gnome/gnucash-sheet.c.

I will be testing this evening.  Before I begin, here is a recap of the different bugs I'm looking for.

I have expected behavior only when using autofill and non-clipboard keystrokes.

If I autofill by typing a few characters and then, let's say, I want to edit the second half of the Description by highlighting with the mouse and hitting the backspace key, then all of a sudden part of the first half of the text becomes highlighted and I can't continue typing without resetting the cursor.

The difference between typing vs. highlighting with the mouse has been monumentally frustrating during data entry.

I will also check if there is any difference when using the Copy and Paste features, which have been giving me repeatable bad behavior, but I use them much less frequently.

When I highlight the second half and press backspace I get...

gnucash_sheet_key_press_event ()
gnucash_sheet_key_press_event_internal ()
gnucash_sheet_clipboard_event ()

There are no changes on screen until after I've continued past that 3rd breakpoint.

I'm not sure where else to look.  The only progress I could make so far was adding another breakpoint that happens after the clipboard and before the cell change...

gnucash_sheet_key_press_event ()
gnucash_sheet_key_press_event_internal ()
gnucash_sheet_clipboard_event ()
gnucash_sheet_key_release_event ()

Repeating the steps from Comment 5, the clipboard event does not occur after pressing Shift, when the selection magically disappears

gnucash_sheet_key_press_event ()
gnucash_sheet_key_press_event_internal ()
gnucash_sheet_key_release_event ()

There were two ways to get shift to remove the selection in comment 5, one involving autofill and the other paste from the clipboard. Which of comments 21-23 goes with each?

Can you double check the key release thing without the debugger? Make a selection as before and hold <shift> down for a couple of seconds. Does the selection disappear while you're holding <shift> down or after you release it?

Without the debugger, the selection disappears while holding the shift key down, yes.

In comment 5, the first scenario (paste, highlight, shift) causes the selection to disappear and I get the events in comment 23.

The second scenario (autofill, highlight to end, shift) causes the selection to expand and I get the events in comment 23.

I see now that the key release event might be irrelevant because the debugger seems to buffer all inputs until I continue the program.  Likewise, if I press multiple keys for an autofill, the screen does not refresh until I continue past all of the key press events.  This gives us somewhat poor precision in terms of timing, because I don't think I can follow your original instruction... "At each breakpoint observe whether the selected text has been removed."

Ah.  I think what I need to do with this gdb thingie is set only one breakpoint at a time, and attempt to determine whether the selection is being corrupted before or after each separate breakpoint.

Yes, now we are getting somewhere.  For both of the comment 5 scenarios, the selection is definitely changing in between these two separate events:

gnucash_sheet_key_press_event_internal ()
gnucash_sheet_key_release_event ()

In other words, the press_event_internal is breaking before the selection changes, but when I delete that breakpoint and add the other, then I can see the key release is breaking after the selection changes.

I've got as far as the breakpoint on gtk_editable_select_region () which is called inside of gnucash_sheet_key_press_event_internal ().  All the way until that point, the selection is normal.

I would suspect that either the call to gtk_editable_select_region is using bad arguments, or the API itself is malfunctioning.  But I'm not certain if it's possible to inspect those arguments from gdb.  Any idea?

Another thing I've noticed is that the gtk_editable_select_region is called more than once, and apparently about half of the calls in this file are using different conditions.  It is possible that the selection is being modified in some unexpected way following the 

sheet->end_sel = sheet->start_sel;

Still not familiar enough with this code or the debugger to figure it out, but that one particular line strikes me as being incredibly lazy.  I wonder if just adding a separate flag instead of overwriting one of the arguments would help clear this up?

This seems like a clue.

Breakpoint 26, gtk_editable_select_region (editable=0x102c33f0, start_pos=1, end_pos=-1) at gtkeditable.c:375

Notice the end_pos argument value!

Hmm, interesting that you're able to get C line information in Gtk: I think MinGW strips their libraries and so I expected that you'd get only assembler code. Good progress, though. Can you step through each line using n<return> and step into functions with s<return>? Are you running gdb from an MSYS shell, Powershell, or CMD?

start_pos=1 end_pos=-1 means select the whole string after the first character.  It's not at all unexpected.

end_sel = start_sel means "select nothing" or "turn off the selection".

"The whole string after the first character" is definitely unexpected if I have a word selected in the middle and I'm only pressing the Shift key 😐

Using CMD.

I have to call it a night.  Will try your "n" and "s" idea later.

The "n" command seems to work for that breakpoint, although not helpful since we already know the arguments are bad.

Breakpoint 1, 0x03566948 in gtk_editable_select_region () from C:\PROGRA~2\gnucash\bin\libgncmod-register-gnome.dll
(gdb) n
Single stepping until exit from function gtk_editable_select_region,
which has no line number information.

Breakpoint 1, gtk_editable_select_region (editable=0x104c83f8, start_pos=4, end_pos=-1) at gtkeditable.c:375
375     in gtkeditable.c
(gdb) n
376     in gtkeditable.c
(gdb) n
378     in gtkeditable.c
(gdb) n
379     in gtkeditable.c
(gdb) n

The "s" command works also.  Seems to give more information.  Not sure how to use it though.

I'd really like to inspect the end_sel and sheet->end_sel values.  Is that possible without the symbols table?

(In reply to Robert Chapin from comment #34)
> The "s" command works also.  Seems to give more information.  Not sure how
> to use it though.
> 
> I'd really like to inspect the end_sel and sheet->end_sel values.  Is that
> possible without the symbols table?
 
Note that you can move up and down the stack: "up" moves back one frame, i.e. to the one that called the current function and "down" moves the other way. You can also jump to a particular frame with "f x" or "frame x" where x is the frame number shown in the backtrace. 

To print a variable value--or any C expression--use "p", e.g. "p sheet->end_sel". Naturally you must be at a frame where that's in scope for gdb to understand. You can also call functions, e.g. "p g_list_length(foo)" to find out how many elements are in the GList foo. If there's no symbol table gdb will say that it doesn't know about the symbol, and even if there is a symbol table the compiler might have decided to keep a variable in a register instead of a stack location and gdb will say something like "end_sel not realized".

That's not working for me.  I just get this every time

(gdb) p send_sel
No symbol "send_sel" in current context.
(gdb) p sheet->end_sel
No symbol "sheet" in current context.

Interesting though, the results I can get just by pressing the backspace key on a highlighted word...

Breakpoint 4, gtk_editable_select_region (editable=0x105803e8, start_pos=49, end_pos=59) at gtkeditable.c:375
375     in gtkeditable.c
(gdb) c
Continuing.

Breakpoint 4, gtk_editable_select_region (editable=0x105803e8, start_pos=49, end_pos=49) at gtkeditable.c:375
375     in gtkeditable.c
(gdb) c
Continuing.

Breakpoint 4, 0x00796948 in gtk_editable_select_region ()
   from C:\Program Files (x86)\gnucash\bin\libgncmod-register-gnome.dll
(gdb) c
Continuing.

Breakpoint 4, gtk_editable_select_region (editable=0x105803e8, start_pos=3, end_pos=-1) at gtkeditable.c:375
375     in gtkeditable.c
(gdb) c
Continuing.

I've also learned that pressing the backspace key in that same situation will trigger all three of the following breakpoints.

Breakpoint 11, 0x00791451 in gnucash_sheet_key_press_event_internal ()
   from C:\Program Files (x86)\gnucash\bin\libgncmod-register-gnome.dll
(gdb) c
Continuing.

Breakpoint 10, 0x007911e9 in gnucash_sheet_direct_event ()
   from C:\Program Files (x86)\gnucash\bin\libgncmod-register-gnome.dll
(gdb) c
Continuing.

Breakpoint 9, 0x0078fabf in gnucash_sheet_delete_cb ()
   from C:\Program Files (x86)\gnucash\bin\libgncmod-register-gnome.dll
(gdb) c
Continuing.

Use those breakpoints and the "n" command, which I hope I'm understanding... it looks like the three calls to gtk_editable_select_region are coming from

0x0078fe77 in gnucash_sheet_delete_cb ()

then

primary_clear_cb (clipboard=clipboard@entry=0x1086c1e0, data=data@entry=0x105803e8) at gtkentry.c:7412

then

0x00791933 in gnucash_sheet_key_press_event_internal ()

I see I failed to explain the difference between "s" and "n" in gdb: "s" means "step" and if the current line is a function call gdb will "step" into it; note that if the arguments to the function are themselves function calls it might step into one of them first. It can get a bit complicated so I'll leave it at that unless you want a more thorough explanation.

The other thing I guess I haven't explained well enough is that you can examine a variable only when the current frame being examined has it in scope. That's what the "no sheet->end_sel in current context" is telling you: That variable isn't in gtk_editable_select_region. You need to change to a gnucash_sheet_ frame. If you use the "bt" command it will list all of the frames with a number and the function name. Event loop apps can have quite deep stacks and you really only need the top few so you can say e.g. "bt 8" to see only the top 8 frames. Look for the first one whose function starts with "gnucash_sheet_". Suppose it's frame #7: You can tell gdb "f 7" to change context to it and *then* you can say "p sheet->end_sel" and if there's enough of a symbol table and it hasn't been optimized out it will tell you what the value is.

Now end_sel is slightly different because it's a local value in some of the gnucash_sheet_ functions. In order to see it gdb must be on one of those functions.

(In reply to Robert Chapin from comment #38)
> Use those breakpoints and the "n" command, which I hope I'm understanding...
> it looks like the three calls to gtk_editable_select_region are coming from
> 
> 0x0078fe77 in gnucash_sheet_delete_cb ()
> 
> then
> 
> primary_clear_cb (clipboard=clipboard@entry=0x1086c1e0,
> data=data@entry=0x105803e8) at gtkentry.c:7412
> 
> then
> 
> 0x00791933 in gnucash_sheet_key_press_event_internal ()

OK. Is that from pressing <backspace> or pressing <shift> with no other key?

Still speaking of the backspace scenario from Comment 36.

I will try playing with the frame commands next.

I seem to get that error on any frame I've tried so far.

No symbol "sheet" in current context.

Trying to use the "s" command properly... it looks like gnucash_sheet_key_press_event_internal calls the gtk_widget_event and that involves the gnucash_sheet_delete_cb.  This kicks off a rather large number of GTK "steps" that I can't see the end of, so I used "c" to bring me to the gtk_editable_select_region.  start=49, end=59.  Then again with the endless GTK steps.  etc.

Without the ability to inspect the end_sel values, I don't think this is going to yield any more information.

Based on my reading of gnucash-sheet.c, it looks to me like pass_on = TRUE could run at line 1715 while the sheet->end_sel is some yet-to-be determined value like -1.

Upon reaching line 1839, the program wants to "forward the keystroke to the input line" and therefore might expect the sheet->end_sel value to be updated.  However, I see nothing in gnucash_sheet_delete_cb that would cause this to happen.  The selection is changing without updating the GnucashSheet members.

At line 1843, we see that the cursor values are not equal, even though they are essentially invalid at this point, and the program wants to "restore the stored selection in case it was eaten."  But as I pointed out above, the selection was never stored after the backspace keystroke was forwarded.

Am I getting at least part of that right?

Or even better, instead of line 1715, we have a false return from line 1819.

Yes, this is all starting to make sense.

The only place where the selection is ever stored is in gnucash_sheet_insert_cb.

By setting a breakpoint on that function, I can see that it never runs during my testing, with the exception of the first keystroke of my autofill.  Therefore, sheet->end_sel = -1 is absolutely correct when the autofill occurs, and the value is never updated.

Expected Flow:

1. Autofill triggers gnucash_sheet_insert_cb and correctly saves sheet->end_sel = -1.

2. Clicking anywhere in the cell clears the selection and triggers gtk_editable_select_region internally, but seems to have no callback in gnucash.

3. Double-clicking on a word in the cell creates a new selection and triggers gtk_editable_select_region internally, but seems to have no callback in gnucash.

4. Pressing backspace triggers gnucash_sheet_key_press_event_internal, which calls gtk_widget_event to trigger gnucash_sheet_delete_cb which uses gtk_editable_get_selection_bounds, but unlike gnucash_sheet_insert_cb it never saves anything to sheet->end_sel.

5. gnucash_sheet_key_press_event_internal then calls gtk_editable_select_region with a stored selection that is multiple times obsolete.

I've been staring at this for a while, trying to infer some purposeful autofill logic.  I think the primary problem is with step 2 above.  When I click into the cell, Gnucash is supposed to know that I'm done autofilling, and it's going to "Clear the saved selection for the new cell."  Right?  But none of the existing callbacks are handling that click.

Sorry, I was knee-deep in the release yesterday afternoon and didn't have the bandwidth to follow along.

With regards to line 1715 in gnucash-sheet.c, masking for GDK_MODIFIER_INTENT_DEFAULT_MOD_MASK is wrong as it includes GDK_SHIFT_MASK, but that won't have anything to do with the backspace key by itself. A shift keypress event by itself shouldn't be getting out of gdkevent.c so one useful datum (separate from the selection changing) would be to set a breakpoint on gnucash_sheet_handle_keypress_internal, press <shift>, and get a backtrace to see how it's getting through.

Your other observations about mouse events not affecting the saved selection in gnucash-sheet are correct and helpful. The selection-saving is intended to operate while handling input of a single when using a multi-press input method for typing in languages like Chinese. It's obviously leaking out and needs a re-think.

As far as I can tell, a bare shift press is not being treated any differently from any other key.  If I autofill, click into the cell, highlight a word, and then press shift, I get the obsolete autofill selection reappearing.

#0  0x03646948 in gtk_editable_select_region () from C:\Program Files (x86)\gnucash\bin\libgncmod-register-gnome.dll
#1  0x03641933 in gnucash_sheet_key_press_event_internal ()
   from C:\Program Files (x86)\gnucash\bin\libgncmod-register-gnome.dll
#2  0x03641bc4 in gnucash_sheet_key_press_event ()
   from C:\Program Files (x86)\gnucash\bin\libgncmod-register-gnome.dll
#3  0x0123dacb in _gtk_marshal_BOOLEAN__BOXEDv (closure=0x8fa1b80, return_value=0x67f4a0, instance=<optimized out>,
    args=0x67f57c "Ea\001\foog", marshal_data=0x36419d2 <gnucash_sheet_key_press_event>, n_params=1,
    param_types=0x8fa1bf0) at gtkmarshalers.c:129
#4  0x68106426 in ?? () from C:\Program Files (x86)\gnucash\bin\libgobject-2.0-0.dll
#5  0x6811fe57 in ?? () from C:\Program Files (x86)\gnucash\bin\libgobject-2.0-0.dll
#6  0x68120927 in ?? () from C:\Program Files (x86)\gnucash\bin\libgobject-2.0-0.dll
#7  0x0120266c in gtk_widget_event_internal (widget=widget@entry=0x107444e0, event=event@entry=0xc01e3c8)
    at gtkwidget.c:7744
#8  0x01204fd5 in gtk_widget_event (widget=0x107444e0, event=0xc01e3c8) at gtkwidget.c:7314
#9  0x012217b4 in gtk_window_propagate_key_event (window=window@entry=0xc020250, event=event@entry=0xc01e3c8)
    at gtkwindow.c:8219
#10 0x01227e55 in gtk_window_key_press_event (widget=0xc020250, event=event@entry=0xc01e3c8) at gtkwindow.c:8252

Bug verified in v3.7.

Tempting to disable autofill, but I think the feature still does more good than harm overall.

Bug verified in v3.8.

This remains the most visible and persistent problem with daily use of this software.

Still experiencing this problem every day when using GnuCash.

Hi Robert, I'm confused about what you're trying to do in comment 20. After you select text using the mouse, what do you expect the backspace key to do? I would expect to use the backspace key only to delete the character before the insertion cursor when no text is selected. I'll try to duplicate your original problem later today.

Hi Chris, when text is selected, the backspace key should remove all selected text and the selection itself.  The bug identified in Comment 47 has gnucash_sheet_key_press_event_internal working with stale selection variables that do not represent the true state of the Description field.  The result is that the selection moves unexpectedly when the backspace key is pressed.

I can duplicate your comment 1 problem (Win 10 in GnuCash 3.8):
1. Paste 2 words into an empty memo field
2. Highlight first word by double clicking on it
3. hit Shift key
Text is unselected and pointer moves to end of text.
Seems to only happen once after the first paste of text into an empty memo field.

Cannot duplicate in Ubuntu 18.04 VirtualBox client with GnuCash 3.4.
CAN duplicate in Ubuntu 18.04 VirtualBox client (Win10 host) with self built maint GnuCash git 3.8b-241-g8fc901fb3+(2020-03-22).

I can also duplicate your problem in comment 20 in Ubuntu 18.04 VirtualBox client (Win10 host) with self built maint GnuCash git 3.8b-241-g8fc901fb3+(2020-03-22):
1. After autofill puts 3 words into memo eg ddd eee fff
2. Double click on last word to select it
3. backspace (OR delete!)
Result is ddd eee with 2nd d onwards selected.
Again, this seems to only happen the first time after autofill.

Re my question in comment 54, I agree backspace should have the same effect as delete if text is selected. I've always used delete.

Chris,

I stumbled upon this bug and maybe have a solution you may want to try...

in gnucash-sheet.c

add these two line after line 1824

        case GDK_KEY_Delete:
        case GDK_KEY_BackSpace:

remove this line at line 1891

    int start_sel = 0, end_sel = 0;

and change this line at 1921

    gtk_editable_get_selection_bounds (editable, &start_sel, &end_sel);

to

    gtk_editable_get_selection_bounds (editable, &sheet->start_sel, &sheet->end_sel);


Not sure if there are other issues in doing this but I have not come across any yet.

I'm heavily reworking this code now to fix bug 797264 and bug 707329, so please don't make any changes. Besides, I don't think that's the right place to fix this problem.

Here's what I've found about the other two bugs:
One underlying problem is that in Gtk3 GtkEntry maintains its own private GtkIMContext and the signal handlers call into the GtkEditable v-funcs and mess with the selection.  On Windows and MacOS its the GtkEntry's IMContext that gets the key events so the GnucashSheet's IMContext event handlers never get called.

Another underlying problem is that GtkEntry (GtkEditable is only an interface description, GtkEntry does the actual implementation) doesn't have cursor_pos, start_sel and end_sel members, it has cursor_pos and selection_bound. gtk_editable_set_position(editable, pos) sets both to pos, meaning no selection, and gtk_editable_select_region(editable, start, end) sets cursor_pos to end and selection_bound to start. Calling both in succession, which we do in several places in gnucash_sheet.c, is pointless.

My solution is to get rid of the sheet's GtkIMContext and use the GtkEntry's via its gtk_entry_im_context_filter_keypress() and gtk_entry_reset_im_context() functions, connecting  gnucash_sheet_filter_keypress_cb to the entry's preedit-changed signal, and reworking the flow of the keypress handling accordingly. The difficulty has been getting the selection behavior right because the GtkEntry's signal handlers mess with it. 

I think that gnucash_sheet_key_press_event should return true if event->is_modifier is set. There's no point in processing a modifier key press, just the later modified character key. That will address the shift key problem (with Chris's insight I was able to reproduce it on MacOS as well) that at least on MacOS applies to any modifier key (see bug 797698). I've already partly sorted the deleting behavior, gnucash_sheet_delete_cb was restoring the selection after deleting its contents; it should instead restore the position except in the account field where a backspace key should delete the selection *and* the character just typed. Ideally it would also restore the quickfill to what it was before the last character entry, but that might be too hard.

I just pushed a series of commits including the change described in comment 58. It will be in tomorrow's master nightly on Windows and Flatpak and in the 3.903 beta. Since my ability to reproduce the problem seems limited it would be great if you could test and tell me if it solved the problem.

Hi John,
The latest build in https://code.gnucash.org/builds/win32/master/ is
gnucash-3.902-2020-05-04-git-3.902-13-ge5e7b30f7+.setup.exe 2020-05-04 03:48	141M

Is that it or am I too hasty?

Not too hasty, but yesterday's build failed because of a dependency problem in reports. Today's is blocked by a hung build in maint. I've got a fix ready for the dependency problem, I just need to push it and then kill the hung build, so look again around midnight UTC.

I tried to test this 12/5/2020 on Windows but GnuCash would not run, I assume because of the same problem I saw someone else had, when perl is not installed. I don't remember seeing that problem had been resolved - has it?

(In reply to Chris Good from comment #62)
> I tried to test this 12/5/2020 on Windows but GnuCash would not run, I
> assume because of the same problem I saw someone else had, when perl is not
> installed. I don't remember seeing that problem had been resolved - has it?

I fixed that yesterday but today's nightly hung. Try tomorrow's build. I'll check it when I get up (around 1400 UTC) and I'll keep kicking it until it completes.

Which it now has: https://code.gnucash.org/builds/win32/master/gnucash-3.902-2020-05-14-git-3.902-120-g09a8bee5c+.setup.exe

Hi John,
Testing master gnucash-3.902-2020-05-15-git-3.902-122-ga81f15540+.setup.exe

This version no longer aborts when started if perl is not installed.

Field editing is much better thanks. 

Problems:
1. In the account code, use End key. then Control-Shift-Left to select last word, OK so far, but when hit Delete key, it makes error sound and cursor goes back to end of field with nothing selected instead of deleting the selected word.
2. In the account code, use Home to go to start of field, use Control-Shift-Right to selected first word. Delete key only deletes character after selection (:), cursor goes to end of field and selects last character.

3. In the account code, select whole field, the type 'ex:a'.
Previous versions (3.10 specifically) would show in the field: Expenses:Auto:Excess:Chris
with 'Auto:Excess:Chris' selected but the new version show the correct account in the list, but only shows 'ex:' in the account field itself. It works OK but is different...

Chris,

That's straying a bit from the bug, which is about the selection in text fields--action, description, memo, and num--after a paste operation.

The transfer account field is a combo controlled by the accounts tree, and there is a significant change in its operation with 3.900: In addition to the sequential auto-complete it will now search the whole tree for an internal match. If you type 'excess' the drop-down list will contain only the accounts with that in their names. At this point key-focus transfers to the drop-down and you can use the arrow keys to select the item you want and enter to commit it to the edit. That's not the case with sequential selection as in your ex:a example. Some of the behavior changes you noticed are because of that, others are due to letting the GtkEntry's input method code handle the keypresses that causes key events to go directly to the input method instead of to the GnuCash event handler. We need to not subvert that because some input methods use the movement keys to select particular meanings from a sequence of keystrokes, but I think that I can fiddle the handling code to treat home and end as "commits" so that the selection string is placed completely in the entry for editing.

In your third observation, have you left and reentered the field or is it still uncommitted? Are you selecting with the mouse or ctrl-a?

John,
Re Third observation: I was either tabbing into the field so it was fully selected, or using Home, then Shift End to select.
I didn't realise you could use Ctrl-a to select the whole field.

I like the new feature of being able to just type in something unique to filter the accounts, or still use the old Acct1:Acct2:Acct3 shortcut.

I've done some more testing using mouse or ctrl-a to select and that works well, apart from the Delete or BackSpace key problem when there is a selection.
BackSpace does the same as Delete and it doesn't seem to matter how one does the selection.

Chris, the issue that *this* bug is about, and we now have bug 797760 for the rest so let's finish the discussion there.

Just installed 3.902-126

Very first thing I tried is autofilling and then pressing Backspace.  The Backspace key no longer works as expected.  Now it removes the selection and erases a single character from the right end of the selection.

Are we sure this bug is fixed?

Delete key doesn't seem to work at all.  If I begin to autofill some phrase and then press the Delete key, the selection is removed and all of the text remains the same.

Let me know if I should open a new bug.  I can see that the selection is not jumping around as it was before this version, however without the ability to edit the Description field this patch is worse than the original problem.

Robert, no, CDB-Man already has as I said in comment 64.

*This* bug, that the selection is deleted by a naked modifier key press when the selection is created immediately after pasting, is fixed.

I'll follow the other bug then.  In the meantime this is not workable and I'll go back to 3.10-57.