The "MetaMask middleware" is the set of middleware for handling methods that
we don't send to the network. This includes signing, encryption, `getAccounts`,
and methods that rely on pending transaction state.
Previously this middleware was setup as part of the network client, despite
having nothing to do with the network. They have been moved into the main RPC
pipeline established in `metamask-controller.js` instead.
This is a pure refactor, and should have no functional changes. The middleware
are still run in exactly the same order with the same arguments.
* Simplify MV3 initialization
The MV3 initialization logic was complicated and introduced race
difficult-to-reproduce race conditions when dapps connect during
initialization.
It seems that problems were encountered after the UI tried to connect
before the background was initialized. To address this, the
initialization step was _delayed_ until after the first connection.
That first connection was then passed into the initialization function,
and setup properly after initialization had begun.
However, this special treatment is only given for the first connection.
Subsequent connections that still occur during initialization would
fail. This also results in the initialization being needlessly delayed,
which is concerning given that our main performance goal is to speed it
up.
* Setup connect listeners before controller initialization
* Add comments
* Add comment explaining isInitialized step
An externally hosted phishing warning page is now used rather than the
built-in phishing warning page.The phishing page warning URL is set via
configuration file or environment variable. The default URL is either
the expected production URL or `http://localhost:9999/` for e2e testing
environments.
The new external phishing page includes a design change when it is
loaded within an iframe. In that case it now shows a condensed message,
and prompts the user to open the full warning page in a new tab to see
more details or bypass the warning. This is to prevent a clickjacking
attack from safelisting a site without user consent.
The new external phishing page also includes a simple caching service
worker to ensure it continues to work offline (or if our hosting goes
offline), as long as the user has successfully loaded the page at least
once. We also load the page temporarily during the extension startup
process to trigger the service worker installation.
The old phishing page and all related lines have been removed. The
property `web_accessible_resources` has also been removed from the
manifest. The only entry apart from the phishing page was `inpage.js`,
and we don't need that to be web accessible anymore because we inject
the script inline into each page rather than loading the file directly.
New e2e tests have been added to cover more phishing warning page
functionality, including the "safelist" action and the "iframe" case.
