Enketo Form in Pages layout error with signature

Description

I am trying to create a form on KoboToolbox with more than one “Signature” questions on Multiple Pages layout. Everything is working fine until I click on “Submit” and the form keep loading forever. I have work on EU server.

I have look into the Community posts and notice that there are several report on the same issues, but I haven’t found a solution or a work around yet.

Steps to Reproduce

  1. Create a new Project and Go to Form Builder
  2. Select “Layout” as “Multiple Pages”
  3. Add 2 questions with Image Type and Signature appearance.

This is the sample XLSForm that I have tested: a6sBTWT7UQvqhsWwnmxpGS.xlsx (5.8 KB)

Thank you in advance for your support.

I also notice that there are some error appearing on the console.log of the browser as well

FYI this looks like the original reported issue: Data loss: not all signature images are uploaded in offline-capable forms · Issue #1043 · enketo/enketo · GitHub

The last comment refers to another fix (that has been merged circa 2022?): Do not update image file on blur if canvas is empty by MartijnR · Pull Request #931 · enketo/enketo-core · GitHub

There is some mention in the former that suggests there is a timing issue between autosave and submit; have you tried waiting a few sec between each signature and hitting submit to see if that makes any difference? Not a solution I know, but it may help debug/reproduce the issue reliably…

2 Likes

Also probably worth testing if you can still reliably reproduce it with a regular/non-Pages layout…

1 Like

Thank you @Xiphware for your response.

I have gone through these GitHub issues and tested several scenario as below:

  1. With two signatures on Multiple Page Layout: :negative_squared_cross_mark: The form is stuck with forever loading even though I have waited for around 1 minute before clicking Submit button.
  2. With two signatures on Single Page Layout: :heavy_check_mark: The form can be submitted without any issue.
  3. With two signatures on Multiple Pages Layout which one signature questions is skip by the logic: :heavy_check_mark: The form can be submitted without any issue

Meanwhile, I have extended my test case to the mobile view as well:

  1. iOS Web Form on Chrome: :negative_squared_cross_mark: I experience the same issue as presented on the desktop view.
  2. Android KoboCollect: :heavy_check_mark: The submission can be made without any issue.

I am looking forward to hearing further about the resolution to this.

Thank you

Thanks for your analysis. So it appears to only apply - but consistently so - to Enketo (not Kobo/ODK Collect) and further only for Enketo’s multi-page layout. Correct?

1 Like

Yeah that is correct @Xiphware. This is what I tested and found out so far.

So I have been able to reproduce this, but only intermittently (!?), with this slightly more simplified form; specifically, removing the max-pixels (the fewer optional extras the better, for debugging at least…)

multi_signature_test copy.xlsx (9.0 KB)

So the first time I tried it it failed and neither signature PNG image was uploaded [I was trying this against a different server, to try to isolate the issue…], which correlates to what you observed. Unfortunately, the error message that popped up disappeared a second later so I couldn’t capture it. And, so far, all my subsequent attempts it has actually worked (!?). I’ll keep trying.

For a sanity check, could you please try my exact form above, several times!, to see if you can also reproduce my observation; that is, this seems to be an intermittent (timing?) issue, and that sometimes it does in fact work.

Understanding whether this might be a timing issue, or an intrinsic logic bug (ie multiple signatures with Enketo pages should never work, today) will be an important data point to debug it. Thanks!

1 Like

Thank you @Xiphware for your time and effort in debugging this issue.

Based no my testing so far, it seems that the problem is around the draw-widget which is used in the file-manager.js. It seems that the system cannot get the input.value for the blob.name

I will further testing with the file that you have shared.

1 Like

Thanks! I didnt actually think removing the max-pixels would necessarily solve anything. But eliminating as many unrelated ‘variables’ possible is a good debug technique. :face_with_monocle:

1 Like

Hello @Xiphware I have tested your file on several web browser: Firefox, Edge, and Chrome but I always get the same error.

I earlier tried to line by line debug the code around blob.name = input.value

When the form is in “Pages” view, the blob become null, so that the input.value cannot be set to name property of blob for both signatures field. However, when the form is in either Default or Grid, the blob doesn’t return null.

I don’t know exactly what is the part of the code that affect the behavior.

It seems to be the issue with the upstream Enketo form.

Hello @Xiphware I have extended my test to another scenario and I now got the same issue.

I was wondering if the second signature is the issue, so I replace the second signature with a select_one and I got the same issue of not able to submit the form.

It seems that the signature is expect to be at the very end of the questionnaire to work for Pages layout.

This is my XLSForm file:
aoDCLYNEK3xpRoxsiLoKUd.xlsx (6.3 KB)

Or perhaps more precisely, having a signature question - under Enketo - on any page but the last will/may result in form submission failure? That is, the signature has to be currently rendered/presented in the UI (possibly scroled off the top…) for submit to work?

1 Like

Note, to address your immediate need, you could try to put both your required enumerator and trainer signature questions in a field-list group - on the final page obviously - to see if that works?

1 Like

Or perhaps more precisely, having a signature question - under Enketo - on any page but the last will/may result in form submission failure?

Yes, that is the result of my test. I tested the Enketo Web Form with the Chrome Dev Tool’s console tab opened side-by-side. I noticed that there is no error right after I signed on the Signature field. Then the error appear when I signed or answer the next question.

That is, the signature has to be currently rendered/presented in the UI (possibly scroled off the top…) for submit to work?

I am not quite sure about your comment on this section. Could you provide some additional details?

@Xiphware I will try this out to see if the issue can be resolved this way.

However, I cannot apply this suggestion to my current project as the signatures are in the consent sections which need to be collected in the middle of the questionnaire. Moreover, based on the questionnaire design, the signatures are not located close to each other that would fit with the field-list group.

Since the some of enumerators will be using iOS, do you have any recommendation beside the fact that they have to use the Enketo web form.

Thank you for your support.

Just an observation (without knowing the intricacies of Enketo, yet…) that the main difference in this case could be that in the non-paged case the signature widget is still osensibly rendered in the browser (but may well have scrolled off the top depending on the form length…), whereas in the paged case it is no longer rendered in any capacity, since you’ve moved to a whole new page. So here, the browser may well have ‘tossed something away’ by the time you reach Submit… Just conjecture at this point. :neutral_face:

Since the some of enumerators will be using iOS, do you have any recommendation beside the fact that they have to use the Enketo web form.

Presently Enketo is the only option for iOS users to run Kobo/ODK compatible XForms forms [although hopefully a native iOS app will make an appearance soon…]

1 Like

I agreed with your observation about the behavior of the form when the user click to the new page, it seems that the signature (file-manager.js) is not able to store the drawing from the canvas as blob.

For non-paged, the blob is generated but it doesn’t have to be stored, so it can be attached with the form submission when the user click “Submit”.

Hope there will be a solution or workaround on this soon.

1 Like

Could you please open a github bug against Enketo summarizing the above [its a little better coming from an actual user who is suffering the consequences, and it’ll ensure you will get immediate updates! :wink:]

1 Like