https://chrome.google.com/webstore/detail/lazarus-form-recovery/loljledaigphbcpfhfmgopdkppkifgno

@Ajaxs86 you appear to have posted your API token here and should probably revoke it.

(I've destroyed the token compromised earlier in this thread.)

it's just likely very complex when we have to save an entire object state ... instead of approximately a single blob of text

Understood. For me personally, the single blob text would be more than sufficient. I don't mind repopulating everything else (assignment, subscribers, tags, customs, etc.) as those usually require much less thought and drafting.

Using a task that you recently created as example, consider T11429. Reasonably wordy + lots of references to other tasks. That kind of thing would take me a good while to draft (10-20 minutes?) to get it to a state where I was happy with it. Other than the main description, I would barely mind at all losing any other fields.

Not sure however on upstream's opinion on saving draft of just the description.

I'd be more comfortable just saving the description if we didn't have CustomFields. I think we do something similar in Phriction today.

However, a task can have an arbitrary number of additional remarkup fields and it feels really bad to me to possibly save "Description" but not "Reproduction Steps", which you might have spent just as long filling out. Even though 95% of the time this would work out fine since most installs don't add big CustomFields, it feels really bad to me the other 5% of the time when we sort of mislead you into thinking the form is saving but only actually save one field.

And I imagine we'd get a task at some point like "save all the fields, you guys are awful at writing software", and we'd be back here anyway but with a hacky one-off bad implementation.

A possible attack on this is via whatever future abuse system we ultimately might build (T10215).

If we eventually build a real abuse system, I think it must operate on the basis of queueing objects and comments in an "unapproved state", consulting the authorities (human moderators, or internal or external robots), then approving the comments/objects and publishing them.

If we built this state in a general way, we could also let you intentionally put your own stuff into the moderation queue ("Save as Draft" or whatever), requiring approval by you at a later time to publish. Although these systems aren't exactly identical, I think they're sufficiently similar that we could make it work, and the difference would basically boil down to a single "personal draft" vs "needs approval" vs "rejected as garbage" vs "published" flag which just gets an extra state or two for "I put this into the holding queue myself".

That wouldn't actually address the original problem here (accidentally setting your computer on fire and losing work) but would address the issue in T12731.

I also can't reproduce the original report in the general case: when I type text into the "Create Task" form, click a notification to navigate away, then press "Back", my text is recovered. This is true whether Quicksand is enabled or not.

We have a narrow known issue in T7029.

(This might be a Firefox-specific thing? I think they made a product decision around this related to HTTPS, maybe?)