Could the draft content persist for the remainder of the session or more semi-permanently? Must it be cleared from the object var when the draft view is collapsed?
BIGGER UI FIX ALT: Ideally, if I were to scroll to the top with too much fervor, it may collapse 90%, but persist at the foot of the view and retain the draft content, to be able to be swiped back up. Similar to the known behavior of the iOS Mail app where a draft email is dropped to the foot of the view, but able to be reactivated. If this is too much coding for a quick bug/feature fix, then the alternate quick fix would be to require a drag down of the draft pane to about 75% of the screen height to enact the collapse/delete of the draft. This could stop a simple drag down off the top of the scrolling up action wouldn't destroy the draft content.
NOTE: right now a slow drag requires nearly a full drag down of the note draft down to the keyboard display to trigger the collapse and delete, however a snappy drag down to about 25% of the draft view above the keyboard is all it takes to flick the draft to collapse and delete its content. That flick is what will delete drafts unintentionally for users since that is the action they are taking to scroll up a long post to the top. Longer posts are even more painful to lose.
Environment
Users repeatedly losing their work is what'll happen with current behavior.
PavleKreator
commented
1 week ago
Describe the bug
Scrolling quickly to the top of a note draft collapses the draft pane and keyboard and deletes the draft contents.
Steps to reproduce
https://youtu.be/pzUTR9Oczcs
Expected behavior
Could the draft content persist for the remainder of the session or more semi-permanently? Must it be cleared from the object var when the draft view is collapsed?
BIGGER UI FIX ALT: Ideally, if I were to scroll to the top with too much fervor, it may collapse 90%, but persist at the foot of the view and retain the draft content, to be able to be swiped back up. Similar to the known behavior of the iOS Mail app where a draft email is dropped to the foot of the view, but able to be reactivated. If this is too much coding for a quick bug/feature fix, then the alternate quick fix would be to require a drag down of the draft pane to about 75% of the screen height to enact the collapse/delete of the draft. This could stop a simple drag down off the top of the scrolling up action wouldn't destroy the draft content.
NOTE: right now a slow drag requires nearly a full drag down of the note draft down to the keyboard display to trigger the collapse and delete, however a snappy drag down to about 25% of the draft view above the keyboard is all it takes to flick the draft to collapse and delete its content. That flick is what will delete drafts unintentionally for users since that is the action they are taking to scroll up a long post to the top. Longer posts are even more painful to lose.
Environment
Users repeatedly losing their work is what'll happen with current behavior.
Additional context
n/a