Can't submit Enketo form - endless loading rectangle (hanging when submit button is pressed)

Hi there, I have a large Enketo form that is being filled out by people in multiple locations on their own laptops/desktops (not just trained enumerators, and not generally on mobile phones). We’ve sent the “online only” version of the survey link.

I have had several users in several parts of the world report that they cannot submit their forms - when they click submit they just see the rectangle progress bar and the blue slider just keeps going back and forth within the rectangle but never finishes. There are no validation error messages or submission error messages, it’s just that it doesn’t get submitted.
20210216 submit rectangle progress bar

I have seen a video of this happening (in Chrome) but have not been able to replicate the issue myself.

Normally (even on a slow computer/slow connection), the rectangular progress bar only appears for a brief moment and then I get EITHER

  • A validation alert modal if the form is well-constructed but the user hasn’t completed the form correctly, or
  • the “submitting” modal

    (the submitting modal is then followed by a confirmation message when done, or in worst case I have seen on other forms that if form badly constructed and could not be evaluated then the user gets a “submission failed” message)

However these users for this form are getting no message at all - just endless progress rectangle when they click submit.

The users reporting issues are not technical enough for me to ask them to use dev tools (console/network), and I thus far haven’t had direct access to screenshare etc. (have just been sent videos and messages).

Does anyone have any ideas re what this issue could be due to and what I should try next?

Thanks in advance!

Could you also let us know the server that you are using? Maybe a sample of your xlsform could help us test the same at our end. It would also be very helpful if your team could capture a video of the same so that we could share the same with our team.

Thanks @Kal_Lam - we’re using a kobo-hosted server (but not the UNOCHA or Kobotoolbox ones) - will DM you with the video I have been sent.

The XLSForm has a large number of repeat groups - based on the one here:
Problems with data in generated repeat groups in Enketo It validates fine on the ODK XLSForm validator and hasn’t had problems in test (or for most users in Prod). Many thanks for taking a look!

@nat, is this seen when a user tries to submit a new submission or when the user tries to edit and submit the edited form? In the mean time would you also mind checking if your team who has reported the issue updated the browser to the most recent version/release.

This is happening for people visiting the public URL to create brand new submissions. None of our validators (who edit existing submissions) have reported any issue like this before. FYI this form has only had relatively minor changes since the last round of data collection (on our old in-house server).

The people reporting issues that I have had definite details on so far were in the Pacific and a couple in the Americas - I have not had direct contact with the end users in either location (just through the regional liaisons) but have been advised that the users are using up-to-date browsers (Chrome). Have sent messages asking for them to send specific Browser version numbers but not sure if I will hear back (as for now the priority is to get the data submitted even if it’s by them sending through an Excel or Word doc for us to then do the data entry at this end to get it into the system )

1 Like

So as a workaround, would you mind uploading your survey projects to one of our publicly hosted servers (either OCHA or HHI) and see if your team who reported the issue happens to see this issue in our servers as well.

I can ask…
In the meanwhile, @Kal_Lam do you know what the actual steps are that happen under-the-hood when the rectangle is whirring along? And whether it is likely to be an issue with client-side processing or server-side processing at that point?
I have since been advised that one of the people has now (on the same computer/browser/data input as before) been able to submit - so while I’d initially been thinking it must be due to client side setup or data input, that now makes me wonder if it’s potentially a server-side glitch perhaps??

@nat, not exactly sure what is causing an issue with the IFRC server (that your survey project is hosted). Maybe we could find something looking at how your survey project behaves with ours. Kindly please let us know what happens so that we could proceed accordingly.

Separate to trying to replicate the specific case, would appreciate please your insights on the general case as per this question:

Thanks a lot!

As far as i can remember it was an Enketo compatibility previously. You could follow this announcement that was made previously:

But as of now, i am not exactly sure on what has been causing this issue. Hence, we would be able to say something if you try to replicate the same in one of our publicly hosted servers.

For reference, you are running Enketo version 2.3.10 on this private instance.

I’m fairly sure that this is a client-side issue. If I set Chrome to “Offline” in the Network tab of the developer tools, I can still see the “Submitting…” modal appear even before any attempts are made to interact with the server:

Looking at the Enketo source code,

  1. I can find the “Submitting…” text in the translations, here, as alert.submission: enketo-express/translation.json at 2.3.10 · enketo/enketo-express · GitHub
  2. Working backwards from there, I see where this message is displayed in _submitRecord(): enketo-express/controller-webform.js at 2.3.10 · enketo/enketo-express · GitHub
  3. _submitRecord(), in turn, is called by an event handler for the submit button: enketo-express/controller-webform.js at 2.3.10 · enketo/enketo-express · GitHub
  4. Nine lines above, I see $button.btnBusyState( true );, which changes the submit button into the loading rectangle that you describe in your first post.

I’d guess, then, that folks afflicted by the infinite loading rectangle are getting stuck inside form.validate(), but it’s going to be very difficult to debug without a way to reproduce the problem or to ask those affected to use the developer tools.

Let’s begin by upgrading this private instance to the latest version of Enketo (2.6.1) and hope that the problem goes away.


I have for the first time got the endless loading rectangle myself - when editing a submission.
Opened dev tools and can see this in the console (not sure at what point it appeared)

Uncaught TypeError: Cannot read property ‘querySelector’ of undefined
at enketo-webform-edit-bundle.min.js:90
at Array.forEach ()
at Object.update (enketo-webform-edit-bundle.min.js:90)
at Boolean. (enketo-webform-edit-bundle.min.js:90)
at Array.forEach ()
at HTMLDivElement. (enketo-webform-edit-bundle.min.js:90)
at li.remove (enketo-webform-edit-bundle.min.js:33)
at Object.remove (enketo-webform-edit-bundle.min.js:33)
at Object.updateRepeatInstancesFromCount (enketo-webform-edit-bundle.min.js:33)
at Array.forEach ()
enketo-webform-edit-bundle.min.js:33 Uncaught TypeError: Cannot read property ‘closest’ of null
at Object.getIndex (enketo-webform-edit-bundle.min.js:33)
at Object.getIndex (enketo-webform-edit-bundle.min.js:33)
at HTMLElement. (enketo-webform-edit-bundle.min.js:47)
at Function.each (enketo-webform-edit-bundle.min.js:22)
at b.fn.init.each (enketo-webform-edit-bundle.min.js:22)
at Object.updateNodes (enketo-webform-edit-bundle.min.js:47)
at Object.update (enketo-webform-edit-bundle.min.js:47)
at Boolean. (enketo-webform-edit-bundle.min.js:90)
at Array.forEach ()
at HTMLDivElement. (enketo-webform-edit-bundle.min.js:90)

It correlates with me having earlier in the form got a grey box that’s non-editable (even though the field should be an input field). When I hover over that field the mouse turns into a red circle with a line through it (this kind of thing, I can’t take a screenshot as the mouse hover-over disappears when screenshotting)

It may be something in the form that is causing the problem - however it’s strange that it doesn’t handle it like any other validation error

Hi @nat, thank you. I’ve upgraded your server to Enketo 2.6.1. With any luck, that will fix this issue! If not, this dev tools output may help us track down the bug.

Not to get totally off topic, but next up is scheduling a full upgrade of the rest of KoBoToolbox (i.e. KPI and KoBoCAT) with Eero. We’ll need a 30-minute maintenance window for that.

1 Like

Hi @jnm thanks for the response - but tbh the upgrade to 2.6.1 makes me nervous as I know that the Enketo 2.6.0 release had to be rolled back on the kobotoolbox servers and so now your main servers are still on 2.5.6… whereas now we’re on 2.6.1 which is ahead of the rolled-back 2.6.0
Will leave it to you and @esario to liaise with respect to the testing and comms and release/upgrade timing etc. as we’re heavily dependent on Enketo (and KoBo) so need to be sure everything is good. Thanks a lot and best wishes from here

1 Like

That’s understandable! Yes, you’ve leapfrogged us, but we did test 2.6.1 on a staging server beforehand, and is already running 2.6.2. Here’s hoping the benefits of the upgrade far outweigh any downsides :crossed_fingers:

For the record, enketo-express 2.6.1 includes enketo-core 5.17.1, which includes openrosa-xpath-evaluator 2.0.2, which fixes the bug that forced us to roll back from 2.6.0 to 2.5.6.


I’m actually also having the same issue. Many users get stuck at submitting. Did the team get around to fixing this issue? Would be much greatful for a fix.

I’m on the humanitarian server

@sibusiso, could you also let us know the browser you are using?

I’m using chrome and all data collectors are using the same.

@sibusiso, could you share your screenshot so that we could understand your issue pictorially?