The bug with our onboarding library integration was introduced in #8873
because of a change in when `completeOnboarding` was called. We hadn't
realized at the time that the onboarding integration relied upon the
onboarding completing event to know when the onboarding state should
be cleared. Because onboarding is now marked as completed earlier, the
state was cleared just as it was intended to be used.
The onboarding completed event has been moved back to where it was
before: after the user exits the "end of flow" page.
The original problem that #8873 was addressing was a routing issue,
where the user would be redirected back to the seed phrase confirmation
page despite already having confirmed their seed phrase. This was fixed
in a different way here, by updating the routing in the first time flow
switch to skip straight to the end of flow page if the seed phrase has
already been confirmed.
This does involve one user-facing change in behavior; if the user opens
any MetaMask UI before navigating away from the end-of-flow screen,
they will still be considered mid-onboarding so it'll redirect to the
end-of-flow screen. But we do mark onboarding as completed if the user
closes the tab/window while on the end of flow screen, which was
another goal of #8873.
This reverts commit f5265c24ab.
Apparently it wasn't unnecessary after all. The Lock page served a few
different purposes. First, it was used to safeguard the seed phrase, in
case the user was interrupted after setting a password. Otherwise
anyone could open MetaMask and see the seed phrase without verifying
the password. Second, the submit function for the initialization unlock
screen also returned the seed phrase, so that it could be set in React
state for the confirmation step. Third, the submit function was also
responsible for navigating back to the seed phrase reveal page.
Removing the lock page had the effect of causing an infinite render
loop if onboarding was interrupted in the "Create" flow after setting
a password but before seed phrase confirmation. That redirect loop has
now been fixed.
A lint error was accidentally introduced recently when two PRs changed
the same area of code (#9793 and #9795). They didn't conflict, and the
lint passed for both, but when combined they left an unused variable.
This page appears to serve the sole purpose of locking the extension
and redirecting back to the base route if the page is refreshed during
the onboarding flow. This ineffectual before the vault has been
initialized, and it's a barrier to resuming interrupted onboarding
flows when done after initialization.
