#8196 Save content before form submission

v1.9.0
closed
None
General
2018-09-24
2018-03-14
No

It would be helpful to save form content before submitting, in case the Antispam spinner/honeypot rejects it, or you get logged out. And obvious restore the content when viewing the form again.

Use localStorage? Clear it after a successful submit? And/or after an hour? Also need to deal with spinner field names properly.

Discussion

  • Kenton Taylor - 2018-03-14
    • status: open --> in-progress
     
  • Kenton Taylor - 2018-03-14
    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -0,0 +1,3 @@
    +It would be helpful to save form content before submitting, in case the Antispam spinner/honeypot rejects it, or you get logged out. And obvious restore the content when viewing the form again.
    +
    +Use localStorage? Clear it after a successful submit? And/or after an hour? Also need to deal with spinner field names properly.
    
    • status: in-progress --> review
     
  • Kenton Taylor - 2018-03-14

    First rev available at kt/8196.

    • Applied only to Markdown inputs for now (and one vanilla text input as POC).
    • User-entered content should be persisted unless/until the form post results in something we interpret as a successful processing (currently an "ok" flash message, or a 302).
     
  • Dave Brondsema

    Dave Brondsema - 2018-03-21
    • status: review --> open
    • Reviewer: Dave Brondsema
     
  • Dave Brondsema

    Dave Brondsema - 2018-03-21

    Nice overall structure, and commenting/documentation. This is going to be great.

    • memorable_forget's _inner should only catch HTTP exceptions I think. Safer and more clear about what its doing.
    • Does the SimpleMDE config autosave:true do anything?
    • there are some sisyphus references I don't think we need
    • blog post successful submit doesn't set memorable_forget cookie. Same for a nested reply.

    memorable.js

    • shouldn't use a SF namespace
    • Memorable.initialize looks to do similar work as Memorable.add, could it call add?
    • name.length != 28 - what is that about?
    • the loopi = 3; i < list.length... also could do .slice() and .join() instead of a loop
    • commenting on a blog post generates storage key /p/test/blog/_discuss/thread/ce912605/post__None is that None ok? same for creating a new discussion topic.
    • memorable_forget cookie only triggers clearing if memorable.js runs on the page? Not too big a deal since the cookie will stick around until you visit a page with it, but maybe better to have clearing behavior run separate from the saving behavior

    User Experience

    • if I intentionally navigate away, it may be surprising to see saved text from long ago when I come back. (even more so if I click "cancel" on a form)
    • maybe could refine our logic to only save for a duration of time? not sure. At a minimum we could have 'cancel' links clear the storage
    • probably a separate ticket, but if i get logged out and then try to do a POST I get sent to /auth/ without any return_to. Probably should have a return_to of the referrer (e.g. wiki edit, ticket edit page)
    • should an intentional logout clear all the local storage? I think so, for privacy.
     
  • Kenton Taylor - 2018-03-23

    New rev pushed with a number of adjustments:

    • Changed this to WSGIHTTPException for readability
    • SimpleMDE autosave does not appear to work; even if it did, it's "forget before successful post" doesn't really meet our needs.
    • sisyphus references are cruft from earlier experiments; removed

    • SF reference removed

    • RE: Memorable.initialize; good catch! it can, and has been changed. Didn't notice how those two had merged after a few refactors
    • RE: length check; antispam input names make those names unusable as identifiers; however, refactored this to use a configurable regex.
    • RE: slice vs loop; good suggestion, changed.
    • the None just happens to be the class that element gets rendered with, and gets used as part of the key since it can be uniquely identified. Might be worth exploring why that is in a separate ticket, but doesn't affect this work.
    • Forget action is now decoupled from the individual inputs managers

    • Cancel links now "forget" the relevant input fields on the form

    • Logout now writes the memorable cookie to forget all (which self-destructs), but also means that memorable.js is registered at the template level, rather than at the EW level.
     
  • Kenton Taylor - 2018-03-23
    • status: open --> review
     
  • Dave Brondsema

    Dave Brondsema - 2018-03-27
    • status: review --> in-progress
     
  • Dave Brondsema

    Dave Brondsema - 2018-03-27
    • invalidInputName could still use a comment explaining that it is to recognize antispam random names
    • might as well remove the autosave: true from simplemde config if its not doing anything
    • on a nested reply:
      • to use a saved value, you have to click the "reply" button again. So its not obvious immediately that your content has been saved (under that particular post), but not sure if we want to automatically expand it
      • When you do start to restore a reply, you have to click into the editor for the text to show up. Bug report https://github.com/sparksuite/simplemde-markdown-editor/issues/344 has a workaround, also mixed info there about whether an upgrade would fix it.
      • the saved value doesn't get cleared after a successful submit
     
  • Kenton Taylor - 2018-03-28
    • status: in-progress --> review
     
  • Kenton Taylor - 2018-03-28

    New rev pushed:

    • Added
    • Removed
    • Nested Reply
    • Leaving, as discussed
    • Fixed
    • Fixed
     
  • Dave Brondsema

    Dave Brondsema - 2018-03-29
    • status: review --> closed
     
  • Dave Brondsema

    Dave Brondsema - 2018-09-24
    • Milestone: unreleased --> v1.9.0
     

Log in to post a comment.