The dapp is now started directly from the `metamask-ui.spec.js` test
module. This makes it easier to run independently, and brings it in-
line with our other E2E tests.
The `--no-timeouts` flag is now used as well, rather than setting the
timeout to `0` within the test. This also brings it in-line with our
other tests.
Mainly this was done to facilitate further refactors which will come in
later PRs.
Only the first parameter, `type`, was ever passed in. The others are
superfluous. The defaults have been set directly instead.
It's a bit silly to set the `rpcUrl` and `nickname` to an empty string,
but to make this more sensible would take much more effort. This at
least is simpler and guaranteed to be equivalent.
* Moving RPC Urls to network constants
* Including RPC url in switchEthereumChain requestData
* Setting project id to var
* Fix built-in networks switch-ethereum-chain
`switch-ethereum-chain` did not work correctly with built-in networks.
It was treating them as custom networks, rather than as built-in
networks. This affected how they were displayed in the network
dropdown, and resulted in slight differences to the network stack used
as well.
The problem was that `updateRpcTarget` was used, which was meant for
custom networks only. Now that `setProviderType` is used in the case of
a built-in network, the behaviour should match the network switcher
exactly.
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
* Moving RPC Urls to network constants
* Including RPC url in switchEthereumChain requestData
* Setting project id to var
* Fix built-in networks switch-ethereum-chain
`switch-ethereum-chain` did not work correctly with built-in networks.
It was treating them as custom networks, rather than as built-in
networks. This affected how they were displayed in the network
dropdown, and resulted in slight differences to the network stack used
as well.
The problem was that `updateRpcTarget` was used, which was meant for
custom networks only. Now that `setProviderType` is used in the case of
a built-in network, the behaviour should match the network switcher
exactly.
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
The CLA bot had its write permissions revoked recently when our
organization-wide settings were updated to restrict actions to read
access by default. This PR restores write access to PRs and to the
repository itself for the CLA bot. It needs PR write access to leave
comments, and needs write access to the repo itself to commit new
signatures.