Provider emits warning: ObjectMultiplex - orphaned data for stream "publicConfig"

[h4l]

I'm using createExternalExtensionProvider() to create a Provider to interact with MetaMask from another browser extension. This works well, but a side-effect is that a lot of warnings are logged to the console:

ObjectMultiplex - orphaned data for stream "publicConfig"

I looked into this, and my understanding is as follows:

• The communication streams between the in page/extension provider and MetaMask itself multiplex multiple named streams over a single connection using ObjectMultiplex from @metamask/object-multiplex
• The warning occurs when an ObjectMultiplex stream receives a message for a named substream that has not been created, so such messages will be ignored.
• The MetaMask extension itself is sending messages to the Provider I create for the publicConfig named substream
  • I can see such messages being received from the Port opened to communicate with MetaMask from my extension
  • It's not that some legacy thing in my extension is using the publicConfig stream.
• MetaMask's own injected contentscript ignores messages for the publicConfig substream, so web pages using MetaMask's provider don't show these warnings: https://github.com/MetaMask/metamask-extension/blob/c40dbb1ec72b91827debb2fffba4097a838f21c7/app/scripts/contentscript.js#L254
• The StreamProvider in this repo that creates the ObjectMultiplex doesn't ignore publicConfig messages:

  providers/src/StreamProvider.ts

  Line 70 in 126a8c8

  const mux = new ObjectMultiplex();

Should StreamProvider ignore these messages itself, like MetaMask's contentscript does? I was tempted to open a PR to do this, but I don't have enough understanding of the legacy context around these messages to know if that makes sense.

It's not currently possible to customise the stream created by createExternalExtensionProvider() to filter these messages before they get to StreamProvider.

[smilingkylan]

@h4l Out of curiosity are these warning messages indicative of anything we need to actually worry about, or are they benign?

Also, how is your extension-to-extension functionality going? I've gotten my extension to work with MetaMask but recently it stopped being able to connect (my useWallet hook stopped being able to retrieve the revevant data from within a content script) but it's great when it works.

[h4l]

Hey @smilingkylan. The warnings are benign as far as I could see. I forget the exact details, but I believe they were related to a historical way that messages were sent between content scripts and the MetaMask extension.

The cross-extension connection works reliably for me as far as I know (I just checked again and it seems OK). I'm using Wagmi to handle the interaction with the wallets. It took a bit of trial and error to get everything working smoothly. My extension is open source, so feel free to check out how mine is working if it's helpful.

• This is where the extension starts the eip6963 provider, I do it in the entry point for the extension's UI, outside the scope of react itself
• This is how the metamask provider isconfigured
• This is the UI component that connects to the wallets

I recall a particular thing to look out for that was screwing things up. At one point I had a component above the WagmiProvider component that was re-rendering, causing wagmi to re-initialise while the extension/app was running. When that happens I think Wagmi would disconnect wallets and generally act weirdly, as it's not expecting to be initialised more than once. So maybe check if that could be happening for you. (This is where my WagmiProvider gets created — pretty much the outermost component)

You can find the link to install my extension from the readme here. I've not been working on it recently though, I was getting kinda burnt out from lack of engagement from Reddit web3/avatar/token community users it's for. 🫤

[smilingkylan]

@h4l Thanks a ton. That is very helpful. I just spent a couple days debugging the MM provider itself just to learn that extension popups and content scripts don't share context. I was wondering why my components weren't getting chainId and account updates, etc. Building extensions is definitely a wild time but a lot of cool stuff we can do with them!

[h4l]

@smilingkylan You're welcome, glad it helped. The extension sandboxing is tricky, I've hit that kind of issue myself a few times when I started building extensions — implementing some functionality in one part of the extension only to realise it was isolated from another part! It's a bit more like building a website with separate backend and frontend compared to just building a single-page app. Extensions are a bit of an underrated superpower I think!

[smilingkylan]

@h4l Were you able to get events like accountsChanged and chainChanged to trigger callbacks or no?

[h4l]

@smilingkylan Yes, changing accounts automatically updates as expected. A caveat though is that it depends how your extension UI is opened and or how MetaMask's UI is opened:

• When your extension UI is a sidePanel and MetaMask is opened from the browser toolbar popup (default), MetaMask acts like it's communicating with the browser tab's page, not your extension sideBar page, apart from when your extension triggers an event, like to sign a transaction or message
• When your extension UI is opened in a browser tab (e.g. loading chrome-extension://<extension-id>/whatever.html) then MetaMask does remember its connected to your extension, and changing accounts updates the extension
• When MetaMask itself is opened in a full tab ("Expand view" option in MetaMask's menu) then it also continues to update your extension when you change accounts in MetaMask.