Undo not correctly displayed in open record in Attribute Editor

[Houska1]

What is the bug or the crash?

When an editing error is undone using the Undo button in the main application Edit menu or the Undo icon in the Attribute toolbar, the change (reversion) is not correctly shown in the currently open record in the attribute editor. At least, until user navigates to a different record and then back again.

Note this is in form not table view.

Steps to reproduce the issue

Open a layer for editing (I tested with gpgk) and open Attribute editor in form view.
Make an edit changing A-->B
Flip back to main window and click Undo or select Undo from Edit menu
In attribute editor, B is still present..
..until you navigate to a different record and return, when A is (correctly) shown

Suspect some signal is not being issued with the Undo or not trapped by the Attribute editor to update its display.

Versions

3.21 Master, 3.20.3. Windows

Supported QGIS version

• I'm running a supported QGIS version according to the roadmap.

New profile

• I tried with a new QGIS profile

Additional context

Prompted by https://gis.stackexchange.com/questions/411533/undo-single-edit-in-attribute-table-qgis/411535

Note a nice small feature add would be to add the undo/redo buttons to the icon toolbar in the Attribute editor window itself. I suspect undoing an accidental munging of a text field in the currently open record is a pretty frequent use case for undo.

[uclaros]

Same as #37418?

[Houska1]

@uclaros, missed that. Related and might make sense to merge, I think, or at least solve at once. However, the description there is not fully accurate as to this situation. You not only need to return focus to the attribute table (as described there), but change to a different record and back (the case described here). Undo is not reflected in the currently active record in attribute editor form view even if the attribute editor window does regain UI focus.

[gioman]

@uclaros agree to close #37418 in favor of this?

[uclaros]

No problem, just keep note that when using the table view of an attribute table, simply bringing focus back to the attribute table is enough for the correct values to be displayed, as I mention on my report.

Also, regarding the undo/redo buttons on the attribute table itself is not a good idea, since users might believe that the undoing will only affect this attribute table.

[Houska1]

Right, it seems to be a difference in current behaviour.

• Table view = bring back focus is sufficient to update (but undo not reflected until focus brought back).
• Form view = bring back focus is sufficient for undo in other than the current record (for instance the expression in the record selector is updated when focus is regained), but you also need to change records to display the undone change in the current record.

Also, regarding the undo/redo buttons on the attribute table itself is not a good idea, since users might believe that the undoing will only affect this attribute table.

@uclaros, true, that could be unexpected behaviour (and would be worth a mention in the documentation). But it seems to me less likely than someone who has just made a boo-boo in the attribute table and is seeking to undo it, but sees no undo button. Perhaps we have different usage patterns in mind: I work on a laptop with a small-ish screen, so most of the time the attribute editor, when open at all, is maximized and covers the main QGIS window. So I empathize with the StackExchange user (who prompted my issue report here) who doesn't know what to do to undo in the absence of an Undo button. I suppose a different usage pattern is on a very large screen or multple screens, where a large canvas is always open, main window is always visible, users may or may not have small-ish attribute editor window(s) open as well, and are busily interacting with all of them?

[uclaros]

I think a safer solution would be to properly handle the undo shortcut within the attribute table window.
I would classify that as a bug deserving its own report and not a feature request!

[Houska1]

Separate bug report for the keyboard shortcut opened per suggestion.