Reproducable crash without saving

[abureaux]

Hello,

I am able to reproduce an issue on the iOS Field App, and wondering if others have a proper workaround. There are two levels to this crash: 1) A usability bug which makes using the field app impossible for some users, and 2) a full crash that wipes out all collected data.

In my testing, the issue requires the following:

1. Mobile field app
2. iOS (don't have an android to test on, but may also happen there)
3. The survey also needs to include multiple pages
4. Need to make use of body::esri:visible
5. Sketch tool somewhere in survey

To recreate the issue, you need to hide at least one page using body::esri:visible. After doing that, you should notice navigation arrows in the mobile app only respond to the second tap (e.g., tap the > arrow once does nothing, but tapping it a second time either jumps to page 3 or tries to send the survey if there are only 2 pages). This is the level 1 issue I mentioned above. There is a "workaround" to this, which is to tap somewhere on screen that isn't a navigation arrow, then on the navigation arrow. It still does the two taps simultaneously, but if you tap on white "space first" it simulates a normal tap when the issues isn't happening. This method is quite finicky, and I would never call this a proper workaround, but it is worth mentioning.

The crash happens when you have a sketch tool in your survey. Essentially, when this button issue is happening and you try to submit a sketch by clicking on the check mark, the first click does nothing, and the second click causes the crash. If you do that "workaround" I mentioned, the sketch will submit normally. Again, I would never call this a reasonable workaround. It's like covering yourself in gasoline and saying everything is fine as long as no one lights a match. This crash will kick you out of the survey, send you back to the main screen, and save no work.

The workaround I have thought of so far are:

• Use the relevant column instead of body::esri:visible. Not reasonable for this project.
• Show all pages without hiding anything. Not reasonable for this project.
• Merge all content for the two pages into one page and hide/show the content there. May work in this one case, but I have many other surveys where this will not work. Tested and doesn't work.
  

EDIT: worth mentioning that I have already opened a case with Esri as this is a rather serious bug. I can't have field staff loosing their days work because the sketch tool bugged out. I will post the bug # here when it's logged.

EDIT2: I merged everything into one page, so a whole page was no longer hidden by body::esri:visible and the issue persisted.

EDIT3: I removed all references to body::esri:visible in a new copy. In this new test, no pages were ever hidden. Issue persisted. I thought it was related to this because I have other surveys where navigation buttons work fine until a page is toggled off via body::esri:visible. There are likely many avenues to arrive at the navigation bug...

[abureaux · Accepted solution]

After way too much testing, this has been logged as a bug.

BUG-000162468: In the ArcGIS Survey123 field app (version 3.18.145), iOS devices do not display the next page after selecting the ‘>’ icon.

[MattEdrich]

Just kudo-ing and responding to keep this topic relevant as I have been running into this issue for months now and find it unavoidable given the size/complexity of the forms that my field teams need. In the past, we have tried to train people to get in the habit of saving their work to drafts every 15-20 minutes or so... However, since the first screen tap fails to register, and it is the first tap on the big 'X' top left of the form to open the Save draft/Continue survey/Exit survey menu, if a user is not paying serious attention to what they are doing and where they tap, they may tap the 'X' a second time and then the entire form just closes without granting the option to save the work.

I am unsure if this bug is caused by some sort of "soft limit" being surpassed by the amount of things going on inside the form, but like I said above, I can't really simplify my forms much more than they currently are (I think). 

In response to you, unfortunately, I have no workarounds. However:

1. My forms do not use sketches, so I don't think that is actually a criterion for this bug to surface.
2. When we recently attempted to train new users on our forms, some of them were Android users and they also seemingly experienced this un-save-able crash phenomenon.
3. This bug doesn't just apply to trying to navigate pages, but affects even select_one responses such that the first tap to a radio button doesn't register anything, and then a second tap anywhere safe on the screen registers the chosen radio button from the first click.

This bug is a major major major issue, and ironically seems to completely undermine the notion of saving something to a draft.

[abureaux]

Some good news on this front!

Hopefully this gets patched soon and this rather scary crash is no longer possible.