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 )
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.
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:
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.
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
That’s understandable! Yes, you’ve leapfrogged us, but we did test 2.6.1 on a staging server beforehand, and https://enketo.getodk.org/ is already running 2.6.2. Here’s hoping the benefits of the upgrade far outweigh any downsides
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.
Greetings @nat , @Kal_Lam@jnm@osmanburcu I have the same exact issue with multiple user spread across the global and failing to submit data due to this same exact infinite submit load. See image
Users have tried to use updated browsers, explorer, Mozilla and chrome but still nothing is helpful. We are running the ODK on digital ocean servers and have a tight deadline to meet and this has been a let down.
Please help with how I can quick resolve this? Did the upgrade to Enketo help to resolve the issue?
It’s 2024 and I’m experiencing the same issue. Most of the forms are not submitting with Enketo and neither are drafts saved. The same issue manifested in odk collect which I linked to kobotoolbox. That rectangle keeps sliding side to side for several minutes and it never gets through: Worse still, my progress is not saved. Has any solution been gotten? Thank you
Hi @mfolayan welcome to the community! I was the user who raised this question in the first place - however I’ve not been doing complicated forms with many repeats recently so haven’t personally hit this issue in a long time.
At the time we did find that it was only on a form that had many nested repeats - is that the case for you? If so it would be worth considering re-designing the form to reduce the number of repeats - make some questions static, or at least not nested.
We also mainly had issues where people didn’t go through the form in order, but rather went back and changed prior answers (which had cascading effect on later form elements). It is definitely worth testing your form with the most complicated scenarios and also on devices with not much memory - as some of the performance aspects of forms with many repeats are affected by the device performance.
Here’s another thread; Can’t submit ODK form - endless loading rectangle (hanging when submit button is pressed) - #19 by LN - Support - ODK Forum