Add Grid editor support to GridTester

[totally-not-ai]

Problem. The Grid row editor (Grid.getEditor()) has no tester support. A
test can open a view that uses the editor, but there is no way to drive it:

var grid = new GridTester<>(component);
grid.doubleClickRow(0);   // the app's listener may open the editor...
// ...and from here there is nothing: no isEditorOpen(), no way to reach the
// editor's fields, no saveEditor() / cancelEditor()

So the whole "user double-clicks a row, edits the fields, saves (or cancels),
the row shows the new values" flow — the reason the editor exists — cannot be
expressed.

What exists today

• GridProTester.setValue(row, column, value) covers GridPro's inline
  editing. That is a different component with a different interaction model and
  does not help with the plain Grid editor.
• The Kotlin layer has Editor<T>._editItem(item) in
  shared/src/main/kotlin/com/vaadin/browserless/component/Grid.kt, which calls
  editItem(item) and then does a client round trip. Nothing calls it and no
  tester exposes it, so it is unreachable from a test as things stand.
• doubleClickRow(row) already fires ItemDoubleClickEvent, so an application
  that wires addItemDoubleClickListener to editor.editItem(...) does get the
  editor opened today. The gap is everything after that point.

Sketch of the missing API on GridTester:

• editRow(int row) — open the editor for a row
• isEditorOpen() and the item currently being edited
• getEditorComponent(int column) / getEditorComponent(String columnKey) —
  the live field component of the open editor
• saveEditor() / cancelEditor()

Points that need deciding before implementing

• Grid.Column.getEditorComponent() only returns the statically set component.
  When a column uses setEditorComponent(SerializableFunction<T, Component>)
  the component is produced per item, so the tester has to hand back the
  instance actually bound for the edited item — the same problem
  getCellComponent already solves for renderers.
• Buffered vs unbuffered editors behave differently on save, so what
  saveEditor() means in each mode has to be pinned down.
• A save can be refused by editor.getBinder() validation. The failed
  validation path is exactly what tests want to assert, so it should surface as
  something assertable rather than a silently ignored save.
• Following the convention used by the rest of the testers ("fail if the user
  could not have done this"), editRow should presumably fail when the grid has
  no editor binder, and interacting with a closed editor should fail rather than
  silently do nothing.

Split out of #175, whose deselect part shipped in #187.

[totally-not-ai]

Analysis

The gap is real: there is no way to drive a Grid row editor from a browserless test today. I verified the behaviour against the current default branch (Vaadin 25.4-SNAPSHOT) with a throwaway probe test; the findings below are measured, not assumed.

How Flow's Grid editor actually works

This is the fact that decides the API shape: the row editor has no client-side UI of its own. Grid has no editor-related @ClientCallable and EditorImpl has no client hooks — opening, saving and cancelling are plain server-side calls (editor.editItem(item), editor.save(), editor.cancel()) that the application wires to its own controls (a double-click listener, a Save/Cancel button in an editor column, a keyboard shortcut). The only thing the framework itself reacts to is an item click: EditorImpl.handleItemClick closes an unbuffered editor when the user clicks a different row.

So "what a real user does" with the editor is: trigger the app's own open action, type in the editor fields, click the app's own Save/Cancel button. There is no built-in interaction for a tester to simulate.

Measured behaviour, with a Grid attached to a UI:

• editor.editItem(item) defers through runWhenAttached + beforeClientResponse, so isOpen() is still false right after the call and only becomes true after a round trip. Any editRow() has to round-trip.
• Unbuffered: requestEditItem calls binder.setBean(item), so every field change writes through to the bean immediately. editor.save() is a documented no-op that returns false and leaves the editor open; closeEditor() closes it.
• Buffered: binder.readBean(item); save() validates and, on failure, returns false, leaves the editor open and marks the offending field invalid with its error message (isInvalid() == true, getErrorMessage() set). The failed-validation path is therefore already assertable — no new mechanism needed for it.
• Records are always read through readBean, i.e. write-through does not apply to them even unbuffered.

Reaching the live editor component

Grid.Column.getEditorComponent() returns only a statically set component. setEditorComponent(Component) internally wraps it as item -> component, and for a genuine setEditorComponent(SerializableFunction) column the per-item instance is built by EditorRenderer.buildComponent(item) (driven from refreshData, and only while the editor is open) and stored in the private EditorRenderer.component field; the renderer itself hangs off the private Grid.Column.editorRenderer. Probing confirms the field does hold exactly the instance bound for the edited item.

So the tester has the same problem getCellComponent had for renderers. There is precedent for how to solve it here — RenderedComponentSupport reads private Flow state from an internal support class with a comment naming the upstream home — but the clean fix is an upstream accessor in vaadin/flow-components, e.g. EditorRenderer.getComponent() (it already keeps two package-private methods "for testing") or a live Column.getEditorComponent() variant.

One related inconsistency worth folding in

TestingLifecycleHook.getAllChildren() collects column.editorComponent for the component tree. Because that is the static accessor, the tree today:

• shows a statically set editor field even while the editor is closed — a component the user cannot see; and
• never shows a function-built editor component, even while the editor is open.

Whatever getEditorComponent(...) ends up using should be what the tree uses too, so find(TextField.class) and the tester agree with each other.

Also: Editor<T>._editItem(item) in shared/src/main/kotlin/com/vaadin/browserless/component/Grid.kt is unreachable dead code (nothing calls it). New code in shared is Java, so it should be deleted rather than wrapped.

Options

Option 1 — reach-only: expose the editor, let the app's own controls drive it

isEditorOpen(), getEditedItem(), getEditorComponent(int column) / getEditorComponent(String columnKey). Opening stays the existing doubleClickRow(row) (or whatever the app wires); saving and cancelling are done by clicking the app's Save/Cancel button obtained from getEditorComponent(...); closing an unbuffered editor by clicking another row is already covered by clickRow.

• Every call maps to something a user can do, so there is nothing to pin down about buffered vs unbuffered and no way for a test to reach a state a user could not.
• A buffered editor with no save control is unusable to a real user too, so the user path is always available in practice.
• Downside: more verbose, and it cannot open the editor for an app whose open trigger the test has no way to fire.

Option 2 — the full sketch in this issue

Add editRow(int), saveEditor(), cancelEditor() on top of Option 1, delegating to editItem/save/cancel plus a round trip.

• Concise tests, covers apps whose open trigger is not clickable from a test.
• Downside: these three calls simulate the application, not the user — a test could save a buffered editor that has no save button anywhere in the UI. saveEditor() also needs a meaning in unbuffered mode, where Editor.save() does nothing by design: either return false (mirroring Flow, and quietly useless) or throw IllegalStateException (clearer, but then the same test body cannot run against both modes).

Option 3 — Option 1 plus editRow(int), save/cancel deferred

Ship the read/reach API and editRow(int) (guarded: ensureComponentIsUsable(), plus a clear failure when the editor has no binder, which Flow itself already reports as IllegalStateException), and leave saveEditor()/cancelEditor() out until a concrete test shows they are needed.

• editRow is the one convenience with no good alternative; save/cancel do have a faithful equivalent (click the app's button).
• Keeps the ambiguous unbuffered-save question unanswered instead of answering it wrongly in public API.

Recommendation

Option 3, with boolean saveEditor() added later only if a real test needs it. Whichever option is chosen, the implementation notes are the same: round-trip after editItem; fail rather than no-op when the editor is closed, when the column has no editor component, or when the grid is not usable; return the live per-item instance for function-based editor columns (ideally via a new upstream accessor, otherwise through an internal support class in the style of RenderedComponentSupport); align the component tree with the same source; and delete the dead Kotlin _editItem.

Open questions for a maintainer: (a) should the tester be allowed to call save()/cancel() at all, given that no user interaction maps to them; (b) if yes, what does saveEditor() do in unbuffered mode; (c) should a closed editor's static editor component keep appearing in the component tree, or should the tree only show editor components while the editor is open (that is a behaviour change to what #214 shipped).

[mcollovati]

Option 3 sounds good. The tester should not have save or cancel methods because those actions depend on how the application is coded to use Editor instance. The tree should show the editor component only if it is open.
Instead or in addition to returning the editor component GridTester could have a ComponentQuery findInEditor(...) method to refine the search for an existing Editor (e.g. searching the save button by text).
Another option could be that editRow returns a GridEditorTester and having similar methods as described above.