You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
May be a limitation we should empathize rather than a bug to fix (?)
TL;DR
Some Stax screen actions produce intermediate screen change which can be understood by Ragger as the final screen it should compare, which triggers errors when using this method (and maybe some others).
Description
For instance:
when using the keyboard, writing a word like "word", the command is sent to Speculos and Ragger waits for a screen change. As characters are written one at a time, it can get the screen displaying w, or wo or wor, or word.
when select fields in a setting list, like a CHOICES_LIST with an initChoice (the corresponding field will be displayed as "selected", in bold with a dot on the right of the screen), Stax will display an intermediate screen where the new "selected" field will be displayed as "selected", then it will display the screen resulting to this selection.
In these case, as these bugs are kinda timing issues, the screens catched by Ragger seem to depend on the host power. A repetitive scenario is that this miscatches are invisible locally, but trigger in the GitHub CI, which is generally much slower.
Workaround
Current workarounds are:
defining navigation callbacks not only with actions, but also arbitrary sleeps to try and jump over the intermediate screen,
using a text-driven stop mechanism, either NavInsID.WAIT_FOR_TEXT_ON_SCREEN or navigate_until_text* methods.
The text was updated successfully, but these errors were encountered:
May be a limitation we should empathize rather than a bug to fix (?)
TL;DR
Some Stax screen actions produce intermediate screen change which can be understood by Ragger as the final screen it should compare, which triggers errors when using this method (and maybe some others).
Description
For instance:
w
, orwo
orwor
, orword
.CHOICES_LIST
with aninitChoice
(the corresponding field will be displayed as "selected", in bold with a dot on the right of the screen), Stax will display an intermediate screen where the new "selected" field will be displayed as "selected", then it will display the screen resulting to this selection.In these case, as these bugs are kinda timing issues, the screens catched by Ragger seem to depend on the host power. A repetitive scenario is that this miscatches are invisible locally, but trigger in the GitHub CI, which is generally much slower.
Workaround
Current workarounds are:
NavInsID.WAIT_FOR_TEXT_ON_SCREEN
ornavigate_until_text*
methods.The text was updated successfully, but these errors were encountered: