fix: breaking auth flow on Safari desktop - prevent confirmation popup

[peterpeterparker]

Description

Auth flow on Safari desktop with agent-js v0.13.x is broken.

Scenario:

• user click on a "login" button in a dapp
• dapp calls authClient.login(...)
• Safari prevent window.open and ask user to confirm the opening of the new window/popup
• user confirm popup
• Safari open II but loose the information #authorize 👉 sign in flow is broken

Root cause of the issue

Following is the result of my debugging and interpretation - i.e. did not find any issue in webkit bugtracker and don't have spec to share.

Browsers prevent the opening of url (window.open or a.click) - with target _blank at least - without user interaction. In Safari, it seems that the browser also considers async callback that are executed within a function that opens new window as no user interaction and therefore prevent their opening.

const sleep = () => {
    return new Promise((resolve) => {
        setTimeout(() => {
            resolve();
        }, 1000)
    })
}

const login = async () => {
   await sleep();
   window.open(...); // 👉 Safari warn user of the opening of a popup
}

Agent-js v0.13.x introduces the usage of IndexedDB which requires async callback to be queried. As the login function checks for the current key in the storage (KEY_STORAGE_KEY), the function matches above criteria - an async callback is executed before window open in the same function - and that's why the issue occurs.

Note that with agent-js v0.12.x there weren't such an issue because, I am assuming, using the local storage is not async.

Solution - workaround

This PR fixes the issue by opening first the window, executing the async callback and then loading the IDP provider URL.

However, this feels like a temporary solution. I can imagine that a proper refactoring of AuthClient, rollbacking to localstorage or dropping the use of separate window would be cleaner solutions.

How Has This Been Tested?

Locally and manually with NNS-dapp.

Screenshots

[peterpeterparker]

A cleaner solution than hacking around is provided in PR #620, therefore I close this workaround.