[IMPROVEMENT] Handle the network connection failure for back-channel polling requests

[mordochi]

Issue to be solved

Because of the restriction on iOS apps that they will lost network connections when they are in the background, back-channel polling requests on iOS browsers will fail once they can't access the network.

And the back-channel fetching mechanism in FCL will just close the wallet iframe once it catches any error, as we can see in the following code snippet.

fcl-js/packages/fcl/src/current-user/exec-service/strategies/http-post.js

Lines 28 to 50 in 937ae10

	} else if (resp.status === "PENDING") {
	var canContinue = true
	const [_, unmount] = await execLocal(normalizeLocalView(resp.local))
	const close = () => {
	try {
	unmount()
	canContinue = false
	} catch (error) {
	console.error("Frame Close Error", error)
	}
	}
	return poll(resp.updates, () => canContinue)
	.then(serviceResponse => {
	close()
	return serviceResponse
	})
	.catch(error => {
	console.error(error)
	close()
	throw error
	})

With this behavior, the back-channel login process fails from time to time, as Blocto requires users to input the OTP codes when logging in, and users might leave the browser app to check the OTP code in their mailboxes.

After users come back to the web app, the wallet iframe may have been closed due to the above connection error, and they have to start the login process all over again.

RPReplay_Final1678123421.MP4

Error logs

Suggest A Solution

Make sure the requests are made only when the window has focus and the network is available. Wait to Fetch the polling requests again once the network is back rather than just close the iframe when the connection is lost.

What are you currently working on that this is blocking?

The back-channel communication between FCL and Blocto wallet

[scottphc]

@justinbarry @JeffreyDoyle Any ideas or directions for this issue?

[chasefleming]

If we can differentiate between a network error and other errors then we can avoid closing the iFrame and the app can continue on. Thoughts?

[scottphc]

Sounds good. The error is different. Another idea is to stop polling when users leave the browser, so no errors are thrown.

[justinbarry]

@scottphc Is this behavior specific to iOS or does it include Android as well?

[scottphc]

@scottphc Is this behavior specific to iOS or does it include Android as well?

This behavior is only on iOS.

[JeffreyDoyle]

Hi @scottphc @mordochi, we have a proposed solution for this issue here: #1623

Please let us know what you think! Thank you again for raising this issue :)

[mordochi]

Hi @JeffreyDoyle, thanks a lot for helping with this issue!

I've just tested the fix but unfortunately it doesn't seem to fix all the login issue. It does reduce the chances that the wallet closes unintentionally(but still happens if you leave the browser for a longer time). However, when I proceed to type the OTP code and move on to the confirm page, the result is never resolved.

So I just dug into the behavior a little bit more.
And I found that it's actually the very first polling request sent when the browser's just back to the foreground was never getting its response, which means the polling function just stuck in

fcl-js/packages/fcl/src/current-user/exec-service/strategies/utils/poll.js

Lines 33 to 35 in 2e5ca45

	resp = await fetchService(service, {
	method: serviceMethod(service),
	}).then(normalizePollingResponse)

Thus the confirm page never got the approved result.

Also, for the case the iframe still closes by itself, it seems like document.visibilityState will be visible by the time we catch the connection error so it never goes in

fcl-js/packages/fcl/src/current-user/exec-service/strategies/utils/poll.js

Lines 37 to 43 in 2e5ca45

	if (
	typeof document !== "undefined" &&
	document.visibilityState === "hidden"
	) {
	await new Promise(r => setTimeout(r, 500))
	return poll(service, canContinue)
	} else {

Therefore, the connection error is still thrown and causes the iframe to close still.

But the good news is that I also found that we can get document.visibilityState as hidden before we make the fetch. So I suppose we can put the above check in L37-L43 before we call fetchService, like

try {
    if (
      typeof document !== "undefined" &&
      document.visibilityState === "hidden"
    ) {
      await new Promise(r => setTimeout(r, 500))
      return poll(service, canContinue)
    } 
    
    resp = await fetchService(service, {
      method: serviceMethod(service),
    }).then(normalizePollingResponse)
} catch (error) {
    throw error
}

Wonder if this looks good to you and please let me know if I can help with the PR :)