Unintentional record deletion after dismissing an unwanted formula entry popup, due to unexpected loss of canvas element focus

Product Feedback Bugs
1

I’m using Coda through the Brave browser on a Mac.

When I’m typing into a Canvas element, I occasionally hit the = key instead of the - key. This causes the formula entry field to pop up. I hit Esc to return to the Canvas. I then hit Bksp in an attempt to delete the unwanted = sign on my canvas. Instead, the entire record is deleted.

Luckily, I can hit Cmd +Z to revert the deletion, but ideally, this shouldn’t be happening.

The bug: when the formula window is Esc -aped, the canvas element is losing keyboard focus, which means that the subsequent press of Bksp triggers deletion of the row.

What would fix this: the canvas element should re-focus after the formula window is dismissed.

2 Likes
2

Thank you for flagging @LxAU! I will be sure to ladder this up to the team to see if there are any quick fixes that can help prevent something like this from happening again.

1 Like
3

Protocol: The “Immortal Row” Defense

I’ve encountered this “Focus Fugue State” before. :wink: It’s a classic conflict between the browser’s focus management and Coda’s rich canvas. When Esc is pressed, the specific cell/control surrenders focus, and since the DOM doesn’t know where to go next, it bubbles up to the nearest focusing container: the Row. In that context, Backspace = Delete Record.

While we wait for the Codans to patch the focus routing, the “clever” fix is to patch the workflow so that Backspace on a row does absolutely nothing.

The “Immortal Row” Pattern

Instead of relying on muscle memory (Ctrl+Z), rely on Schema Defense:

  1. Enable Locking on your table/view.
  2. In Advanced Settings, allow “Add rows” and “Edit values”.
  3. Disable “Delete rows”.

Now, when the focus bug bites and you hit Backspace, Coda will simply ignore you. The row is immune to keystrokes.

“But I actually need to delete things…”

To handle legitimate deletions, implement a Soft Delete mechanism, which is a best practice for data integrity anyway:

  1. Add a checkbox column: [isDeleted].
  2. Filter your main views to show [isDeleted] != true.
  3. Add a button to the row: “Archive” (or a Trash icon).
  • Action: ModifyRows(thisRow, [isDeleted], true)
  1. (Optional) Create a “Trash Can” page that shows only [isDeleted] == true rows, allowing you to “Restore” them or permanently flush them.

This transforms a UI bug into a UX feature: Greater Safety.

1 Like