Stop reloading dapps on network change allowing dapps to decide if it should refresh or not

[joshstevens19]

Hi I am a blockchain developer who works for FunFair. We really appreciate the epic work you're doing on your extension thanks a bunch and keep it up, now the juicy part! 😄

https://medium.com/metamask/breaking-change-no-longer-reloading-pages-on-network-change-4a3e1fd2f5e7

We read this article around 9 months ago about no longer reloading the page on network change. When we first heard about it we all jumped for joy as this was a HUGE UX problem for us. Losing all the current state on refresh causes millions of issues. When you released and then straight away rolled back we were disappointed but knew why. So many dapps now depend on this behaviour so just bringing a breaking change like that just didn't make sense. 9 months later we are here now, still with the huge pain of it reloading.

Thinking closely about this I think it was a mistake deciding on a breaking change, my view is dapps should have control of this feature, dapps should be able to decide if it should reload or not leading to a best of both worlds solution. This extends on to what i have changed in this PR.

You introduced something called ethereumProvider which you create your web3 instance with. This holds methods like enable() which the dapps have to call to see if the user has given permission or not. If not then it will pop up the MetaMask screen for approval. So dapps are openly using the methods on window.ethereumProvider now.

What I propose is a simple easy solution which solves this. Yes it may not be the perfect solution but it allows best of both worlds until you're ready to focus on completely killing the auto-refresh.

If we added another method on the ethereumProvider callled autoRefreshOnNetworkChange which is default set to true i.e. it will always reload like it does now meaning old dapps don't need to change a thing. Now if dapps want to disable this all they have to do is:

window.ethereum.autoRefreshOnNetworkChange = false;

on startup of the app and then it will just return in the auto-reload.js file if that is not true. This even gives the flexibility for some parts of the dapps (say legacy) to reload and some old dapps which can't support this straight away can change it feature by feature and roll it out.

I think we know now that this isn't your main focus, you have the mobile MetaMask and loads of awesome things you're doing. But this issue has a lot of attention and is the single biggest annoyance of the extension to date as you can see by the 23 comments on this issue:

#3599

Dapps today are pushing the barriers of what they can do and to allow that to happen this needs to change ASAP. Something like this could solve all this until you're ready to kill it completely.

I am looking forward to hearing your thoughts.
Thanks for spending the time reading

Josh

[danfinlay]

Wow, my first impression: Wonderfully elegant solution to a problem that felt like it stuck us between a rock and a hard place. And a PR no less!

I'm going to share this with the team a little bit more, but this looks simple enough to intelligently merge it pretty eagerly. Thanks a ton for the contribution!

[danfinlay]

One non-blocking thought is we could move the flag into the metamask-inpage-provider module itself, to improve portability to mobile and connected extensions, but that optimization can be made later. The immediate win is here.

[joshstevens19]

Awesome news! Super happy you like it. I was going to do a PR in the metamask-inpage-provider but I didn’t want to have to do 2 PRs on 2 different repos, I wanted to address the solution and outline it like I have in 1 PR first. Like you said moving it into the inpage provider repo wouldn’t be hard and can come next.

As you guys appreciate dapps now are becoming a lot more smarter and this will move us in the correct direction to allow more complex state driven dapps to work without a reload. Thanks for being so welcoming and supportive with the solution I presented.

In terms of merging do keep me updated with the discussion with the team etc, the sooner we could get this in the better!

Cheers Dan 👍

[danfinlay]

Okay so we're willing to merge this as an "experimental feature" for now. Going forwards, things we will want to do before we consider it finalized (you can help if you'd like):

• Get it in our metamask-docs repo (listing its experimental status)
• Open an EIP and optionally an ethereum-magicians post to bring the change to the attention of other client developers.

Once a version of this is merged as an EIP, we will consider it stable and update our docs to reflect that. For now, let it be considered an experiment that will be live soon!

Bonus: Long term we are hoping to allow ways of requesting additional networks without user involvement, and so long term it should be increasingly common for users to not ever be directed to select a network, new apps should all have what they need via constant API, reducing the danger of not setting this flag in the future.

[joshstevens19]

Thanks Dan that’s awesome news!

Does the experimental features actually go live? so we can expect this in the next release?

I can do those things above, il get that sorted and PRs up for you tomorrow to finalise everything, anything else I can do to help give me a shout!

Thanks for your quick response and fast merge.

great stuff guys!!

[joshstevens19]

Oh and also you may want to close/explain on this bug what has happened, as this is where the whole debate came from.

#3599

👍

[joshstevens19]

Hey @danfinlay docs have been updated here - MetaMask/metamask-docs#9 👍