Why edits save instantly, but new bookmarks don't

Linkgarden has two editing models that look inconsistent until you see what each one is protecting.

Editing an existing bookmark: everything saves live

The detail area has no Save button and no Cancel button. Every change is written as you make it:

• toggling the favourite star
• picking a folder
• adding or removing a tag
• committing the name or the address
• leaving the notes field

There is nothing to forget to save, nothing to lose by closing a window, and no state where the screen disagrees with what is stored.

This works because the bookmark already exists. The worst outcome of an accidental edit is a wrong value on a record you can fix — and, for the fields that are easy to fumble, Linkgarden adds an explicit commit step.

Name and address are the exception

Both are read-only labels until you click them. Only then do they become text fields.

• Return, or clicking away, commits.
• Esc abandons the edit and restores the previous value.

That is a deliberate speed bump on the two fields where a stray keystroke would do real damage — a mangled address makes a bookmark useless, and it is not obvious from a glance that it happened.

The address gets one more guard: what you type is parsed before it is stored. A bare example.com becomes https://example.com. Something that cannot be parsed at all is refused with an alert, and the text is reselected so you can fix it rather than losing it. Clearing the field clears the address.

Creating a bookmark: a modal with a Save button

New bookmarks go through a sheet, and that sheet is the opposite design. Nothing you type is stored anywhere until you press Save. Cancel discards everything, having never touched the database.

The reason is that a live-editing new-bookmark form would have to create the record first, which means an empty bookmark exists the moment you open the form — and stays there if you change your mind. Sequestering the draft avoids the whole category of accidental empty records.

Save stays disabled until the form has a name, an address, or a note.

Deleting: two stages, with one exception

Deleting a bookmark stamps it with a deletion date and moves it to Recently Deleted, where it stays for 30 days. It is not gone; it is filtered out of every other view.

This is why there is no confirmation dialog when you delete. The dialog would be asking about an action that is already reversible.

The exception is a bookmark with no content at all — no name, no address, no notes. There is nothing to recover, so Linkgarden deletes it for real, and that does ask first.

Note

A folder or a tag assignment does not count as content. A bookmark that only ever got an auto-assigned tag is still treated as empty, so a tag can never keep a blank record alive.

Folders and tags work the other way round: deleting one always asks, because there is no recycle bin for them. Their bookmarks survive — they just lose that folder or tag.

What this adds up to

Action	Reversible how
Editing a field	Retype it
Cancelling a new bookmark	Nothing was written
Deleting a bookmark	Restore it within 30 days
Deleting a blank bookmark	Not reversible — confirmed first
Deleting a folder or tag	Not reversible — confirmed first
Emptying Recently Deleted	Not reversible — confirmed first

Every irreversible action asks. No reversible one does.