fix(Syncing): cancelling syncing flow should not result in error dialog

[Seitseman]

Closes #11908

What does the PR do

When user cancels or closes KeycardPopup.qml, it will be 'Rejected'. Appropriate state will be signaled up to the interested objects. ProfileLayout.qml reacts to the 'Rejected' / 'Accepted' state by discarding any error messages from the nim layer.

Affected areas

ProfileLayout.qml, KeycardPopup.qml, SyncingView.qml

Screenshot of functionality (including design for comparison)

• [x ] I've checked the design and this PR matches it (No designs for cancel/discard/X of Sync Device flow)

[status-im-auto]

Jenkins Builds

:grey_question:	Commit	:hash:	Finished (UTC)	Duration	Platform	Result
:heavy_check_mark:	118c95b5	#1	2024-05-07 21:56:51	~7 min	tests/nim	:page_facing_up:log
:heavy_check_mark:	118c95b5	#1	2024-05-07 21:57:28	~7 min	macos/aarch64	:apple:dmg
:heavy_check_mark:	118c95b5	#1	2024-05-07 22:00:22	~10 min	macos/x86_64	:apple:dmg
:heavy_check_mark:	118c95b5	#1	2024-05-07 22:01:23	~11 min	tests/ui	:page_facing_up:log
:heavy_check_mark:	118c95b5	#1	2024-05-07 22:08:13	~18 min	linux/x86_64	:package:tgz
:heavy_check_mark:	118c95b5	#1	2024-05-07 22:19:49	~30 min	windows/x86_64	:cd:exe
:heavy_check_mark:	db7ebc43	#2	2024-05-10 14:43:40	~7 min	tests/nim	:page_facing_up:log
:heavy_check_mark:	db7ebc43	#2	2024-05-10 14:44:07	~7 min	macos/aarch64	:apple:dmg
:heavy_check_mark:	db7ebc43	#2	2024-05-10 14:44:47	~8 min	macos/x86_64	:apple:dmg
:heavy_check_mark:	db7ebc43	#2	2024-05-10 14:48:21	~11 min	tests/ui	:page_facing_up:log
:heavy_check_mark:	db7ebc43	#2	2024-05-10 14:52:31	~15 min	linux/x86_64	:package:tgz
:heavy_check_mark:	db7ebc43	#2	2024-05-10 15:04:48	~28 min	windows/x86_64	:cd:exe

[Seitseman]

It looks like instead of closing the dialog and resetting the state we still call keycard_go.keycardCancelFlow and since there is an error returned from keycard lib, we hide the error popup. Is it correct?

It would be good if you added a video screencast that the issue is resolved.

To me it sounds legit that after user either cancels or closes the sync->authenticate dialog, "Backend" should still do proper canceling of its data flow and go through de-init states in its state machine. But then it will confuse the end users if after (partially) entering password but "Canceling" the flow they might observe that app still tries to do syncing. Maybe another way to fix the issue is to introduce another state, e.g. "discard", and allow keycard lib to silently de-init itself.

[Seitseman]

@Seitseman changes here are good and they fix what we want, but, the real issue is happening earlier and we need to handle it before we get to the qml side.

What's the thing when the user wants to setup syncing, we firstly display popup asking user to authenticate the action and then after successful authentication we're preparing a connection string for syncing and if all that goes well we display syncing popup.

No in case of canceling authentication popup, we don't need to proceed further at all, don't need to try to create a connection, but just abort everything.

So I am pretty sure that you can revert all changes done here and just need to add condition like this

if password.len == 0 and pin.len == 0:
    return

as the very first check of this function https://github.com/status-im/status-desktop/blob/master/src/app/modules/main/profile_section/devices/module.nim#L108-L116

I've tried that fix initially, but then if I enter my sync password partially, but then decide to Cancel or "X" the sync dialog that error will return.

[IvanBelyakoff]

@Seitseman changes here are good and they fix what we want, but, the real issue is happening earlier and we need to handle it before we get to the qml side.

What's the thing when the user wants to setup syncing, we firstly display popup asking user to authenticate the action and then after successful authentication we're preparing a connection string for syncing and if all that goes well we display syncing popup.

No in case of canceling authentication popup, we don't need to proceed further at all, don't need to try to create a connection, but just abort everything.

So I am pretty sure that you can revert all changes done here and just need to add condition like this

if password.len == 0 and pin.len == 0:
    return

as the very first check of this function https://github.com/status-im/status-desktop/blob/master/src/app/modules/main/profile_section/devices/module.nim#L108-L116

@saledjenic yes, that is what I expected more or less. just thinking why this onLoggedInUserAuthenticated even called, since user cancelled authentication.

[saledjenic]

I've tried that fix initially, but then if I enter my sync password partially, but then decide to Cancel or "X" the sync dialog that error will return.

Ok, let me try it.

@saledjenic yes, that is what I expected more or less. just thinking why this onLoggedInUserAuthenticated even called, since user cancelled authentication.

@IvanBelyakoff let me try to explain. There are 2 popups. One is for syncing, another one is for authentication. Authentication popup is a global thing. It works in a way, that you can run it from any part of the app, sending a signal for authentication and you will always get the response, in both cases (either authentication went well or not). It's important to be like that cause in all places in the app authentication is used in an async way. Now, if you get empty values for pin and pass, means the authentication didn't go well. Now when we speak about this use case...

1. user wants to set up a new and click on the button to open the syncing window
2. the first thing we do is to ask him to authenticate that action 2.1 if authentication went well we're displaying syncing popup and error placeholder in that popup will be used to display errors that occurred during the syncing 2.2 if the password/pin was missed, that will be displayed within the authentication popup (syncing popup has nothing with it) 2.3 if the user cancels the authentication process it means that he doesn't want to continue with setting up syncing and we just need to close the authentication popup

That's the whole story.

[saledjenic]

@Seitseman I've tested it in the latest master with the following change and that's the only one I did:

And here is the result (tested canceling clicking on the cancel button, on the X button, clicking outside the popup and pressing Escape key):

https://github.com/status-im/status-desktop/assets/86303051/0ace7b8d-a8fc-4e03-b6f3-dd956648004f

[Seitseman]

@saledjenic , I've checked what would happen when there is already some parts of password entered, or even when user enters the password but then cancels the flow. Updated the PR to check for if password.len == 0 and pin.len == 0: return