dApp Tx sign dialogs - clicking outside of dialog should not close the dialog

[benjthayer]

SIWE / Tx dialogs issued via WalletConnect for signing inside Status should not be dismissible by clicking outside of the dialog.

Accidentally dismissing the dialog in this way cannot be construed as an explicity rejection of the sign event and leads to ambiguity about what should be done with the dApp request.

Eventually, the user should be able to click the [X] icon button top right of the dialog to dismiss the request - but this should only be implemented when the user can re-launch the sign request dialog via the corresponding notification centre item. Until the notification centre items are implemented, it may be safer to remove the close [X] as well as the ability to click outside of the sign dialog to dismiss it - this way, the user must make an explicit in-the-moment call to reject or sign the sign request.

We should apply this logic/behaviour to all Signing dialogs - even those initiated from inside Status via Send/Swap/Bridge etc for consistency.

cc @caybro

[caybro]

CC @alexjba

Gonna do the same for the Swap sign dialog unless you guys @Khushboo-dev-cpp @dlipicar object

[alexjba]

@benjthayer WDYT if we try to activate the app as well whenever this popup shows up? It has an expiry date and we'll need the user attention when a sign is requested.

[caybro]

@benjthayer WDYT if we try to activate the app as well whenever this popup shows up? It has an expiry date and we'll need the user attention when a sign is requested.

Great idea actually; won't work on Linux though as the policies prevent you from stealing the focus but why not :)

[benjthayer]

@benjthayer WDYT if we try to activate the app as well whenever this popup shows up? It has an expiry date and we'll need the user attention when a sign is requested.

Hey @alexjba , as discussed on the user stories call, perhaps we show an OS notification when there is a sign request - which, when clicked, refocuses the app. I think that's where we landed - correct me if I'm wrong.

I can add this to the flows, but do you want to check feasibility first from an implementation perspective?