Approve a dApp request on one screen, not two

[Fuma419]

Follow-up to #278. That PR made the dApp approval screens look right; this one removes a step from them.

The extra step

Approving a dApp transaction was two screens for one decision:

1. Review the transaction, press Sign.
2. A password dialog opens on top and asks you to Confirm.

The dialog also covered the transaction being agreed to, so the details were hidden at the moment of confirming.

Now

The password sits in the approval footer. Pressing Sign is the confirmation, with the transaction still visible above it. A wrong password is reported under the field and the request stays open for another try — previously the failure path was the dialog's to interpret.

Hardware accounts keep the dialog, because those flows have device prompts and a QR exchange to run and no password to collect. The button reads Sign with device so it is clear a dialog is coming.

Shape of the change

New inlineSignAction.jsx owns the footer (password field, primary action, cancel) and is shared by both approval screens, so the transaction and message flows cannot drift apart again — that drift is what left the sign-message screen two design generations behind in #278.

Both screens now route the inline path and the device dialog through one pair of return-to-dApp helpers (returnSignedTx / returnSignError), instead of each caller inlining controller.returnData + window.close().

The signing calls themselves are untouched: the same signTx(...) / signDataCIP30(...) with the same arguments. Only where the password comes from has changed.

Verification

sign-data-page-render.test.js grows to 9 tests covering the new footer:

• password on the page, and no Confirm dialog button anywhere
• primary action disabled until a password is typed
• success returns { data } and closes
• wrong password shows in place, returnData is not called, popup stays open, and a retry then succeeds
• any other failure is handed to the dApp as { error }
• hardware account has no password field and is told why

sign-tx-refresh.test.js keeps guarding the footer contract, now including that only hardware routes to openModal.

Full unit suite: 902 passed.

Left alone deliberately

The enable → signTx double popup. Those are two separate CIP-30 requests from the dApp, usually seconds apart, and collapsing them would mean granting a connection and a signature on one screen. Not worth the ambiguity.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
lucem-wallet	Ignored		Sep 4, 2026 2:43pm UTC