ethereum.send never resolve when page is loaded on browser launch (chrome)

[wighawag]

Describe the bug
After launching chrome, the page/tab that is loaded at launch has window.ethereum present but none of the call to it respond

To Reproduce
Steps to reproduce the behavior:

1. ensure chrome load a page on launch (it can be the previous page)
2. ensure chrome is not running
3. launch chrome
4. open the console
5. see the log (see below)
6. type ethereum.send('net_version') in the console and see the promise never resolve
7. reload the page
8. do step 4 to 6 and you ll see the promise resolving

This is what the console shows in step 5:

contentscript.js:1 MetamaskContentscript - lost connection to MetaMask Background Multiplex
s @ contentscript.js:1
contentscript.js:1 MetamaskContentscript - lost connection to MetaMask muxed traffic for channel "provider" failed.
s @ contentscript.js:1
contentscript.js:1 MetamaskContentscript - lost connection to MetaMask muxed traffic for channel "publicConfig" failed.

Expected behavior
I expect all call to ethereum.send to either resolve or fail

Browser details (please complete the following information):

• OS: Windows 10 (64 bit)
• Browser: chrome
• MetaMask Version: 7.2.1

[wighawag]

Any updates on this ?

To reproduce you just need a webpage that use window.ethereum and that you set your browser to load it on launch. Or alternatively that you set your browser to load the pages "where you left off", and make sure you are on this page when you shutdown the browser.

[gwn]

I'm experiencing the exact same problem on Chrome 78 on both my Linux and Windows 7 oses. I also managed to reproduce this both on my dapp and several popular dapps using MetaMask. Seems that this is affecting everybody.

[gwn]

Related: #6817

[gwn]

I was looking for ways to circumvent this for some time and I found that the only thing I can do is to use the experimental ethereum._metamask.isEnabled method, which thankfully returns false if MetaMask is not working properly. So I can warn the user to refresh the page or something.

The problem is that this method is marked as deprecated and apparently will be removed in Q1 2020.

So I can't do anything else but to ask MetaMask maintainers to keep this method around until this issue is resolved. Or at least communicate us the exact removal date when you have one. Because I'm going to rely on this method in my dapp since it's the only workaround afaik.

[tmashuang]

I would like some clarification on

1. ensure chrome load a page on launch (it can be the previous page)
2. ensure chrome is not running
3. launch chrome

Would my Chrome setting On Startup need to be on Continue where you left off? It seems that the issue you are describing requires Chrome to be closed and reopened to the tab that is reopened on startup.

If this is the case, that would mean either we are not reinitializing the background when Chrome is disconnecting them on browser close. This would require a look if Chrome allows us to reconnect and reload the background processes. I would assume this is achievable since uBlock works the correct way in these situations but their implementation could be different.

I am guessing that when the browser is reopened and the tab is manually refreshed the connection is reestablished again in this situation.

[wighawag]

Yes that's correct if you use " Continue where you left off" and you were browsing the application using metamask, then this issue will appear. It could also appear if the application is set as the home page.

[xrow]

I see the same issue.

[wighawag]

Hey @bdresser any attempt to reproduce it on your side?
This is a pretty serious issue : metamask is not usable on website that get first loaded when you start chrome
Plus it is very easy to reproduce.

[wighawag]

@danfinlay Any way this could be look at ?

[wighawag]

This issue is still present in version 8.0.4

[Gudahtt]

Related to #5936

[blabno]

According to https://docs.metamask.io/guide/getting-started.html#connecting-to-metamask

You should never initiate a connection request on page load. You should only initiate a connection request in response to direct user action, such as clicking a button.

[wighawag]

@blabno the issue happen when you do a request at any point, as described in the reproduction step above

[FatTigerWang]

This problem still exists in Metamask 10.12.1, I was able to reproduce it in Chrome and Firefox.

[Dope-Ass-Ninja]

Problem still exists. Chrome (Brave) and Firefox, multiple machines. MM v 10.15.1

[Dope-Ass-Ninja]

as @blabno mentioned, you should never initiate a request on page load. This is a correct statement but is not related to the issue many developers have been facing with the MetaMask extension.

Reproduction Example
Save this link somewhere you can access outside of a browser (like discord or even a shortcut):
https://docs.metamask.io/guide/getting-started.html#connecting-to-metamask

Open that link, thus opening a new browser session (no tabs / pages open), and try using MetaMask's button for initiating a connection.

You will get a message that the connection was successful from the website, but you should not receive a MetaMask pop-up or wallet connection. You will also be able to find the below errors in the dev tools console upon direct page load:

MetaMask: Content script lost connection to "MetaMask Background Multiplex". undefined
contentscript.js:1 MetaMask: Muxed traffic for channel "metamask-provider" failed. undefined
contentscript.js:1 MetaMask: Content script lost connection to "MetaMask Background Legacy Multiplex". undefined
contentscript.js:1 MetaMask: Muxed traffic between channels "provider" and "metamask-provider" failed. undefined
contentscript.js:1 MetaMask: Muxed traffic for channel "publicConfig" failed. undefined

Please provide some comment on this issue as I've been finding references to this dating back to 2019.

[wighawag]

Any updates on this ?

This is a severe issue that is not addressed since 2019.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity in the last 90 days. It will be closed in 45 days if there is no further activity. The MetaMask team intends on reviewing this issue before close, and removing the stale label if it is still a bug. We welcome new comments on this issue. We do not intend on closing issues if they report bugs that are still reproducible. Thank you for your contributions.

[github-actions]

This issue was closed because there has been no follow up activity in the last 45 days. If you feel this was closed in error, please reopen and provide evidence on the latest release of the extension. Thank you for your contributions.

[Mattijah]

Still experiencing the same issue. The request either doesn't resolve or it takes like 3 minutes for it to return anything back. There is something going on with the connection. Can't believe this has been just closed

[jiexi]

Hello all. Thanks for reporting this. Could you help us verify something by disabling preloading in your Chrome settings? This can achieved by:

Opening chrome settings
Searching for "Preload"
Toggling the "Preload pages" setting to off
After you do this, are you still able to reproduce the bug you are seeing?

I suspect this is a Chrome specific issue with contentscript to background script connections being dropped on prerendered pages. Thanks!

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity in the last 90 days. It will be closed in 45 days if there is no further activity. The MetaMask team intends on reviewing this issue before close, and removing the stale label if it is still a bug. We welcome new comments on this issue. We do not intend on closing issues if they report bugs that are still reproducible. Thank you for your contributions.

[github-actions]

This issue was closed because there has been no follow up activity in the last 45 days. If you feel this was closed in error, please reopen and provide evidence on the latest release of the extension. Thank you for your contributions.