Page MenuHomePhabricator

Drafts for unsaved objects
Open, WishlistPublic

Description

I'm often, drafting up a new task, taking my time and choosing my words, when I end up navigating away from the page by accident. Sometimes I reflexively click a phabricator notification, sometimes I accidentally search in the same tab for some relevant information, sometimes I sleep my computer in the middle and chrome bugs out when it wakes back up, etc. Whenever this happens, I lose all the work I put into making the task and have to start all over again. This makes me very sad whenever it happens.

It seems like there is a mechanism already for saving drafts of comments (and state transitions) on existing tasks. I would personally find it helpful to have something similar for new tasks.

Event Timeline

sshannin created this task.Aug 7 2016, 8:51 PM
This comment was removed by epriestley.

@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.)

epriestley triaged this task as Wishlist priority.Aug 8 2016, 3:53 PM

This is nice in theory, but I suspect it may be very complex to implement in practice.

The code for saving comment state isn't really directly applicable to saving entire form states: comment states are pretty limited, but object states are much more complex.

The stakes for object-drafts are also higher than for comment drafts: it's generally fine if we don't preserve actions associated with a comment perfectly, since they're usually not too important and not too difficult to recreate (until fairly recently, we did not save actions at all, and saw few requests). However, it's disastrously bad if you rely on us to save, e.g., the content of custom task text fields as a draft and we throw it away by accident (for example: across version upgrades, or across configuration changes). This is also the kind of thing that's very difficult to test manually, very difficult to even remember to test manually, and very difficult to encode in a unit test.

This problem also affects all forms on the web, and there's nothing particularly unique to Phabricator task forms. Safari, at least, had a global warning for this at one point, although it seems to be gone in recent versions (you can google for DebugConfirmTossingUnsubmittedFormText to find users complaining about it). @chad links to an extension above (Lazarus) to make losing form data more difficult in Chrome. It looks like Lazarus is also available for Firefox. (And for Safari, although apparently it no longer works in recent versions of Safari.) If you find yourself losing data from web forms, you might want to evaluate these extensions.

There's at least a task about this in Firefox too, although it has been open for 15 years and the comments are about what you'd expect:

Which part of this is hard? ... DO IT!!!!!!!
https://bugzilla.mozilla.org/show_bug.cgi?id=48333#c73


sometimes I sleep my computer in the middle and chrome bugs out when it wakes back up, etc

This sounds like a Chrome bug. We're very hesitant to work around bugs in other software just because Phabricator is more nimble. Taken to the extreme, this would result in Phabricator being full of workarounds for bugs in other software. Google probably has 1000x the engineering resources dedicated to Chrome that we have dedicated to Phabricator, and we'd like the onus to be on them to fix bugs in their product.


I don't think this is a bad idea necessarily, it's just likely very complex when we have to save an entire object state (and then protect that object state across changes and upgrades) instead of approximately a single blob of text, and consequently difficult to prioritize.

epriestley renamed this task from draft for new tasks to Drafts for unsaved objects.Aug 8 2016, 3:54 PM
epriestley updated the task description. (Show Details)
epriestley edited projects, added EditEngine; removed Maniphest.

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?)