RequestManager depends on deprecated event when used with MetaMask

[rekmarks]

Refs: https://github.com/ethereum/web3.js/blob/1.x/packages/web3-core-requestmanager/src/index.js#L101-L108

web3-core-requestmanager depends on the provider data event, and makes assumptions about its state. I'm not sure if this even was ever intended for consumer usage in the misty past, but by now, it's superfluous.

For MetaMask providers (ethereum.isMetaMask && typeof ethereum.request === 'function'), please use the EIP-1193 message event, described in our docs: https://docs.metamask.io/guide/ethereum-provider.html#message

The message event emits with an object of the form { method: string, data: any }. For method === 'eth_subscription', the result is given as data.result.

[GregTheGreek]

Thanks for this catch! We've been looking into ways to add further e2e tests with metamask to help catch these bugs (the new release caused a few issues).

Right now we're thinking about using the mm app example and integrating it to our existing UI test, but it is ultimately a manual process. Any ideas on potentially automating it?

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions. If you believe this was a mistake, please comment.

[GregTheGreek]

@koraykoska

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions. If you believe this was a mistake, please comment.

[rekmarks]

The breaking changes (extension version ^9.0.0) are live on Firefox, and are rolling out to Chrome right now. We are receiving reports of broken subscriptions using web3@^1.3.0.

[rekmarks]

See the following snippet for where we emit the relevant events: https://github.com/MetaMask/inpage-provider/blob/d474406b2d8a99b8303e5e269a86dd5a070c7963/src/MetaMaskInpageProvider.ts/#L269-L276

You should use the message event, per EIP-1193: https://eips.ethereum.org/EIPS/eip-1193#message

[rekmarks]

The following PR should fix it, although I haven't tested it. Feel free to edit/adopt/re-implement as required: #3864