-
Notifications
You must be signed in to change notification settings - Fork 5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix #19941 - Correctly show network name and selection when chainIds collide #19947
Conversation
CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes. |
ui/selectors/selectors.js
Outdated
const filter = | ||
providerConfig.type === 'rpc' | ||
? (network) => network.id === providerConfig.id | ||
: (network) => network.chainId === currentChainId; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thoughts on using provider.type
instead? chainId
works, but it makes the result order-dependent. type
is reliably unique for built-in networks, so that should make this a little more reliable even if the order changes later.
It looks like providerConfig.type
is available on the network list entries as network.providerType
: (network) => network.chainId === currentChainId; | |
: (network) => network.providerType === providerConfig.type; |
Alternatively, since you've set the id
field to the type for all of the built-in networks, maybe this would work:
: (network) => network.chainId === currentChainId; | |
: (network) => network.id === providerConfig.type; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome idea!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my mind, the rpcUrl
(if available) would be the most reliable. rpcUrl || chainId
might do the trick?
This should also make custom RPCs more robust, I think (it looks like multiple custom RPCs with overlapping chainId
can still collide if the url is not taken into account in either case).
(IMO more generally, it would make sense for multiple reasons that rpcUrl
would become a mandatory field, which would mean simplified logic in places like this)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using id
might be more forwards-compatible if we start introducing more custom RPC fields alongside rpc URL, making it no longer unique. We did get a request to support additional headers, where the header might determine the chain.
a458f13
to
85608c0
Compare
4451a03
to
9c6b9cc
Compare
The code looks good, but I'm seeing consistent e2e test failures for the test "finds all recent RPCs in history" |
ce06ab6
to
2225629
Compare
Builds ready [2225629]
Page Load Metrics (1608 ± 45 ms)
Bundle size diffs
|
Codecov Report
@@ Coverage Diff @@
## develop #19947 +/- ##
========================================
Coverage 69.47% 69.48%
========================================
Files 988 988
Lines 37297 37301 +4
Branches 9980 9982 +2
========================================
+ Hits 25912 25916 +4
Misses 11385 11385
|
4a1b384
to
c80a858
Compare
Builds ready [2225629]
Page Load Metrics (1565 ± 33 ms)
Bundle size diffs
|
6f07329
to
6c5156d
Compare
76c7559
to
736065d
Compare
Builds ready [f1c94b4]
Page Load Metrics (1655 ± 47 ms)
Bundle size diffs
|
This was fixed with this change https://github.com/MetaMask/metamask-extension/pull/19947/files#diff-50c876d2ff4c618bf7018751413649df82021af47d93754663e8bf7522bea68fL199-L200 Previously, there were two networks in the fixtures with the same id, and one of those networks would result in a 404 if a request was sent to it. So metamask was attempting to connect to the wrong network. |
Explanation
This bug was occurring because we were selecting the first network with a given chain ID. That means if there's a custom network with a chain ID that matches a pre-installed network (i.e. Mainnet having
0x1
and a localhost0x1
chain, like the issue cites), we show the wrong network selected in the Network Picker despite switching to the correct network. This is a labeling issue, not a functionality issue.To fix this issue, I fork the logic for retrieving the current network by checking to see if it's a custom network (by checking for
type=rpc
and searching for the network by configuration ID. If a pre-installed network, we use the chainId.Screenshots/Screencaps
NetworkFix.mov
Manual Testing Steps
ganache --chain.chainId 1
Pre-merge author checklist
Pre-merge reviewer checklist
If further QA is required (e.g. new feature, complex testing steps, large refactor), add the
Extension QA Board
label.In this case, a QA Engineer approval will be be required.