Crash when board setup changes but board position is not 0

[herzbube]

The application requires that board setup is made before any actual moves occur. The UI is therefore built to prevent board setup actions by the user once the board display a board position beyond 0. As a final safeguard against violations of the rule, the class HandleBoardSetupInteractionCommand contains a check that, if it fails, raises an exception that causes the application to crash.

Since the release of version 1.6.0 of the app, a relatively high number of crashes (about 100 crashes from 17 different users in the last 90 days) have been reported that are due to this check. The issue needs to be investigated and fixed.

[herzbube]

The only source that triggers the execution of HandleBoardSetupInteractionCommand is the method handleTapFrom: in TapGestureController. The trigger occurs only if the property UiSettingsModel.uiAreaPlayMode has value UIAreaPlayModeBoardSetup. The intention is that the user can activate this mode only if the board position is currently 0, and that the app changes the mode to something else (usually UIAreaPlayModePlay) when the user navigates to a board position beyond 0.

No obvious code defects were found that allow the user to violate the mode condition. Some cases were found, however, where the user can circumvent the condition by making iOS recognize a tap gesture while another tap gesture is already in progress.

Case 1

• Start a new game and play at least one move.
• Go to board position 0
• Tap and hold the forward button
• While the forward button is tapped, tap on "Game actions"
• Once the "Game actions" menu is displayed, release the forward button. The board now changes to board position 1.
• From the "Game actions" menu that is still open, select the option "Set up board". This option should not be available! Board setup mode is supposed to be available only when the current board position is 0. The option exists, however, because the menu was generated while board position 0 was still active.
• Tap on the board to place a stone. The alert "Future moves will be discarded" is now displayed.
• Confirm the alert by tapping "Yes".
• The app crashes now.

Case 2

• Start a new game and play at least one move.
• Go to board position 0
• Tap on "Game actions", then select the option "Set up board".
• Tap and hold the forward button
• While the forward button is tapped, tap on the board to place a stone. The alert "Future moves will be discarded" is now displayed.
• Once the alert is displayed, release the forward button. The board now changes to board position 1.
• Confirm the alert by tapping "Yes".
• The app crashes now.

Case 3

• Same repro steps as case 1, but from the "Game actions" menu select the option "Set up a side to play first"

Case 4

• Start a new game
• Set up the board with at least one stone
• Play at least one move
• Go to board position 0
• Tap on "Game actions", then select the option "Set up board".
• Tap and hold the forward button
• While the forward button is tapped, tap on the "Discard all setup stones" button. The alert "Future moves will be discarded" is now displayed.
• Once the alert is displayed, release the forward button. The board now changes to board position 1.
• Confirm the alert by tapping "Yes".
• The app crashes now.

Note: Originally it was thought that these cases cannot be reproduced on a big iPhone (UITypePhone) because there tapping + holding the forward button is blocking other interactions. This was found not to be the case, i.e. the two cases can be reproduced on all devices.

[herzbube]

The cases described in the previous comment require the user to perform quite convoluted actions, so it seems unlikely that these are the causes for all the crashes that occur in the field. It seems more likely that other, simpler ways to provoke the crash exist. However, even if further causes are found, any conclusive solution for the issue requires that the described cases are also handled.

The root cause for the described cases is that iOS allows further gestures while the user is performing a tap+hold gesture on a toolbar button. I currently can't think of a way how to prevent that since the application is not in control of handling toolbar button tap gestures. While it might be possible to somehow hook into iOS' gesture handling on a low level, the approach feels too complicated. A much simpler solution is to remove the cause of the crash.

Decision:

• For case 2, no longer raise an exception in HandleBoardSetupInteractionCommand. Instead react by displaying an informative alert and aborting command execution.
• For cases 1, 3 and 4 add checks similar as in HandleBoardSetupInteractionCommand to the other commands that handle board setup (ChangeUIAreaPlayModeCommand, DiscardAllSetupStonesCommand and SetupFirstMoveColorCommand)