Freehand Line: Edit/Correction feature acts strangely if interrupted

[shaunanoordin]

UI/UX Bug on Experimental Feature

Follows #3446, specifically issue 2 in this review

Context: in PR 3446, we modified the (experimental) Freehand Drawing Line tool, allowing users to edit a selected segment of the freehand line (FHL).

Problem: the correction feature acts very strangely if interrupted.

Details:

• The edit/correction works perfectly if user does all the following: 1. create FHL mark, 2. double click on FHL to place start point, 3. click on FHL to place end point, 4. drag start point draw new segment... 5. ...drag to end point to complete/confirm new segment
• If the users encounters an interruption during steps 2 to 4 (the "editing" stage), the mark becomes "unstable"
• An interruption is any of the following:
  • User clicks on the canvas, triggering the "draw new FHL" action (very easy to accidentally do)
  • User changes the active Drawing Tool
  • User selects another existing mark
• "Unstable" can mean any of the following:
  • FHL mark stays in editing mode, even though this isn't a valid state to finish on
  • FHL starts "shrinking" due to confusion over what's the "current" selected segment
  • FHL is broken into multiple segments (difficult to replicate)
• (special case) If a user has already placed the Start and End marks for the segment, and then proceeds to click on the FHL mark again, the FHL mark gets very confused as to which bits are selected, especially if you alternately click on the sections before the Start/after the End mark.

Status

Low to medium priority, because while this definitely a problem that borks UI/UX and the data submitted, (1) the FHL still works if the user follows exact procedures, and (2) the FHL is still an experimental tool.

Low urgency since no active project (i.e. Correct-A-Cell) is using FHL's edit/correction feature at the moment.

Automatically assigned to Jim as a follow up to 3446, but please un-assign if you have other things on your place 👌

[eatyourgreens]

Here’s a video from #3446, in Chrome 104, where I clicked off the line during drawing then selected it again and continued drawing without problems.

https://user-images.githubusercontent.com/59547/184857368-4bb18f05-43c0-4aac-89aa-9bfdcfee7b51.mov

[eatyourgreens]

Here's another screen recording, also in Chrome 104, where I interrupt drawing by selecting a different mark, then return to the original line without problems.

https://user-images.githubusercontent.com/59547/185590597-702bf922-0485-4b5d-82ae-21dd5701a6bb.mov

[eatyourgreens]

Last example, also in Chrome 104. Here I start drawing a freehand line, change tools and make some different marks, then return to finish the freehand line.

https://user-images.githubusercontent.com/59547/185592831-2cb85987-fd4e-46f5-a89d-d0afbccfc33c.mov

[eatyourgreens]

I think this issue was fixed by https://github.com/zooniverse/front-end-monorepo/pull/3446/commits/dc3489fdf7fb37da4ee125c26d956f33445c7f11 (part of #3446.)

[shaunanoordin]

Some documentation following out discussion earlier:

(Note 1) An interrupted FHL mark can still be submitted, causing very wonky data to be submitted. For example,

• I draw a line from x=200 to x=700
• then I start editing a segment from x=400 to x=600
• and then submit while the FHL mark is still in editing mode

• The submitted FHL annotation is just an array of points, and has no way to indicate a "temporary line break"/missing segment that was being edited.
• As a result, we'll see the submitted annotation's array suddenly "jump" from x<400, and then to x>600

[shaunanoordin]

(Note 2) Here's a video of the special case, where continuously clicking on an FHL mark (that's in already edit mode) causes the mark to "shrink" (permanently lose segments)

https://user-images.githubusercontent.com/13952701/185624452-39611519-383f-446e-80f7-afe71998c63c.mov

As discussed, this is a result of the Edit FHL feature not having a proper "undo" stack. Marking the Start and End points immediately remove the segment from the data array, so continuous clicks (marking new End points) causes portions of the array to be permanently removed. (If we had the undo stack, we'd revert to the original array before removing the newly marked/updated segment)