Always return to main menu at the end of get_wallet_address

.github/workflows/lint-workflow.yml

@@ -1,28 +1,26 @@
-name: Code style check
+---
+  name: Code style check
 
-on:
-  workflow_dispatch:
-  push:
-    branches:
-    - master
-    - develop
-  pull_request:
-    branches:
-    - master
-    - develop
+  # This workflow will run linting checks to ensure a level of uniformization among all Ledger applications.
+  #
+  # The presence of this workflow is mandatory as a minimal level of linting is required.
+  # You are however free to modify the content of the .clang-format file and thus the coding style of your application.
+  # We simply ask you to not diverge too much from the linting of the Boilerplate application.
 
-jobs:
-  job_lint:
-    name: Lint
-    runs-on: ubuntu-latest
+  on:
+    workflow_dispatch:
+    push:
+      branches:
+        - master
+        - main
+        - develop
+    pull_request:
 
-    steps:
-      - name: Clone
-        uses: actions/checkout@v2
-
-      - name: Lint
-        uses: DoozyX/clang-format-lint-action@v0.12
-        with:
-          source: './src'
-          extensions: 'h,c'
-          clangFormatVersion: 12
+  jobs:
+    check_linting:
+      name: Check linting using the reusable workflow
+      uses: LedgerHQ/ledger-app-workflows/.github/workflows/reusable_lint.yml@v1
+      with:
+        source: './src'
+        extensions: 'h,c'
+        version: 12

src/handler/get_wallet_address.c

@@ -217,5 +217,18 @@ void handler_get_wallet_address(dispatcher_context_t *dc, uint8_t protocol_versi
         }
 
         SEND_RESPONSE(dc, address, address_len, SW_OK);
+
+#ifdef HAVE_NBGL
+        // Workaround for a glitch when get_wallet_address is called right after a UX flow that has
+        // a long confirmation screen (e.g. register_wallet), as processing this command sometimes
+        // lead to the "Processing..." screen not being cleared at the end of the command.
+        // By forcing to show the dashboard, we avoid it; however, this is not a perfect solution,
+        // as it results in cutting short the duration of the "Address verified" status.
+        // This only happens on Flex and Stax, and only for complex policies. Therefore,
+        // we use the workaround for non-default wallets, and only on NBGL devices.
+        if (!is_wallet_default) {
+            ui_menu_main();
+        }
+#endif
     }
 }