Skip to content

Intermediate screens break the navigate_and_compare method #114

@lpascal-ledger

Description

@lpascal-ledger

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions