Unable to sign into Firefox with password (wasm eval warning)

[markmhendrickson]

Submission remains pending forever here:

Reported here and seen by yours truly as well: https://discord.com/channels/621759717756370964/625538774230892545/913782930281754664

Seems similar to https://github.com/hirosystems/stacks-wallet-web/issues/1902 for Chrome

[timstackblock]

https://github.com/hirosystems/stacks-wallet-web/issues/1750

[beguene]

I could not really reproduce the 'infinite' but it can be quite slow sometimes even on chrome. I am working on 2 code fixes which significantly reduce this time and should also fix https://github.com/hirosystems/stacks-wallet-web/issues/1750 and https://github.com/hirosystems/stacks-wallet-web/issues/2014

[kyranjamie]

@beguene will this involve addressing https://github.com/hirosystems/stacks-wallet-web/issues/1877 to remove the request to Gaia on every sign in? Curious what other changes there are to make this faster.

[beguene]

@kyranjamie yes this will address #1877 too

[andresgalante]

The current plan to address this issue is to first

• Reduce Gaia dependency #1877
• Add metrics to understand the impact of that change

If the above doesn't show enough improvemnts then we'll consider changes on Argon2's settings https://www.notion.so/hiropbc/Argon2-Optimisation-f7132735a496499dbb94b045ccf37b52

[beguene]

@andresgalante Regarding "Add metrics to understand the impact of that change", there is already a metric added by @kyranjamie before, which englobes the decrypt function and the call to Gaia. Now that we removed the call to Gaia on unlock, we can track the same metric which will only measure the decrypt function (which includes argon2 hash). There is no need to add any new metrics I think.

[beguene]

Moving it to backlog as we need to check the analytics. This could be picked up again in a few weeks.

[markmhendrickson]

Which metric should we check here exactly? And is the idea that we need to confirm whether this problem is indeed still happening (commonly) in production?

[danieltanfh95]

is there anyway I could help to accelerate this? it's blocking users on firefox, making it seem that Stacks/Hiro is very unreliable / rug.

[zommuter]

Can anyone explain what the issue here is? Why does the unlocking take forever if it works at all on Firefox? This is horrible UX and probably one of the major reasons for a lack of users. Here's a screenshot from the profiler, though I guess you already know that the problem lies in decryption-worker.js i.e. src/shared/workers/decryption-worker.ts.

Not sure how reliable the profiler's line reference is, that would mean the import argon2, { ArgonType } from 'argon2-browser'; already causes the problems 🤷‍♂️

[markmhendrickson]

@zommuter did you intend to comment on this issue with the same content as here?

@beguene what metrics can we check here exactly to gauge the volume of this problem?

[beguene]

@markmhx you need to check 'start_unlock' and 'complete_unlock' 'complete_unlock' has a 'duration' properties in ms You should also check 'start_unlock that is not followed by a 'complete_unlock'. Those are users that could not complete the unlock or exited before completion.

[markmhendrickson]

Note that the last few comments in particular appear related more closely to https://github.com/hirosystems/stacks-wallet-web/issues/2014 than a wasm eval warning per se.

[kyranjamie]

This issue is still open https://github.com/hirosystems/stacks-wallet-web/issues/1750 and I wonder if some users are running into it: where an error's thrown, and the behaviour is an infinite spinner.

Regarding users giving up, maybe we can fire an event to background script to log an event, when the session is closed.