Graphite icon indicating copy to clipboard operation
Graphite copied to clipboard

In the graph, a click that deselects a node loses the entered input field value

Open Keavon opened this issue 10 months ago • 1 comments

In the graph, if you have a node or layer selected, the Properties panel populates its parameter widgets. If you type a value in a widget's input field, and attempt to confirm that new value by clicking out of the input box elsewhere in the graph (to deselect everything, or select a new node) then the Properties panel ends up clearing all the widgets before the updated value has a chance to be saved.

https://github.com/user-attachments/assets/4e5b7d37-175f-426b-8c31-db50e6a9ee5e

However, this isn't an issue in the Layers panel or the viewport (rather than the graph). Deselecting a layer in the Layers panel (by clicking in the empty space beneath the layers, or clicking on another layer) or in the viewport (by clicking the artwork background or another layer) does successfully commit the input field's updated value before the widget disappears. So whatever approach is taken in those cases needs to be applied to the case of the graph in regard to (presumably) message ordering.

Keavon avatar Apr 08 '25 03:04 Keavon

Clicks in graph causes deselect on mouse down.

This is problematic as the widget data in rust is immediately destroyed. Therefore any messages from the frontend in an onDestroy callback will reference invalid widget ids.

I'm not really sure about the best way to solve this. However this probably isn't a good first issue.

Possible solutions:

  • Maintain an old copy of all the callbacks in the backend and use as a fallback in case the widget id is invalid.
  • Dispatch an event before deleting a widget
  • Only modify on mouse up
  • Defer property update events to the next animation timestep

0HyperCube avatar May 28 '25 11:05 0HyperCube

I can't reproduce this error with the updated codebase, so it's probably gone away for good.

daniil-loban avatar Nov 09 '25 01:11 daniil-loban

This seems to be "fixed" as a regression reported in #3353.

Keavon avatar Nov 09 '25 01:11 Keavon

This was fixed because of the PropertiesPanelMessageDiscriminant::Refresh is now deferred until the next animation frame (rather than being executed immediately). This means that the lose focus event can be processed before the new widgets are created.

0HyperCube avatar Nov 09 '25 10:11 0HyperCube

Fixed in #3337.

Keavon avatar Nov 09 '25 21:11 Keavon