The bulk of the work is being done in the ModalStateMachineOwner now - split out from the main ExperienceRenderer, as this is Modal render context specific logic. There are a variety of options available to observe changes in the view tree, using a ViewTreeObserver. This starts out by watching scroll, global layout changes, and draw updates - detecting when the UI is idling by waiting for a 1 sec period after all updates have concluded, before attempting a retry.
The retry is controlled by listening for StepErrors that are marked recoverable. Only selected errors are such type, like "no target element found" and "multiple matching targets" - things that could be resolved by UI updates. Each time a retry is triggered, all the listeners stop, and if another error occurs, then they re-attach and keep trying. If a screen view is processed - retry handling also stops (permanently for that failed experience).
This would support a tooltip step failing when it was the first step in a group - new container presentation, as well as a subsequent step in the group - where the container would be removed, then re-presented on the desired step, if it recovers.
Stacks on error/retry handling in #528
Creating a draft here for feedback on approach.
The bulk of the work is being done in the
ModalStateMachineOwnernow - split out from the main ExperienceRenderer, as this is Modal render context specific logic. There are a variety of options available to observe changes in the view tree, using a ViewTreeObserver. This starts out by watching scroll, global layout changes, and draw updates - detecting when the UI is idling by waiting for a 1 sec period after all updates have concluded, before attempting a retry.The retry is controlled by listening for StepErrors that are marked recoverable. Only selected errors are such type, like "no target element found" and "multiple matching targets" - things that could be resolved by UI updates. Each time a retry is triggered, all the listeners stop, and if another error occurs, then they re-attach and keep trying. If a screen view is processed - retry handling also stops (permanently for that failed experience).
This would support a tooltip step failing when it was the first step in a group - new container presentation, as well as a subsequent step in the group - where the container would be removed, then re-presented on the desired step, if it recovers.