Metamask freezing in Firefox and v8.1.6-8.1.9

Describe the bug MM freezes itself while doing certain operations, e.g. activating gas and nonce controls.

Steps to reproduce (REQUIRED)

Go to 'Settings'
Click on 'Advanced'
Toggle 'Advanced gas control'
MM freezes

Expected behavior For the toggle to switch state

Browser details (please complete the following information):

OS: MacOs 11.0.1
Browser: FF 83.0
MetaMask Version: 8.1.9

Additional context (Error Messages, etc.) Verifying a back up phrase got me the same effect in 8.1.8, clicking whatever the button is to continue after all individual words have been selected does nothing. Could be related.

Same freeze on Windows & Mac OS, Firefox 84 and latest MM extension. Remove/Install again, same problem. Same error when want to rename account, or another 3nd floor deep click i think

Thanks for the report! We have been hearing many reports of issues like this, but we haven't been successful yet in reproducing the problem.

When you say "freezes" do you mean that the tab becomes entirely unresponsive? e.g. does the browser identify it as being unresponsive and prompt you to close it? Or do you just mean that the button fails to work and you get stuck there waiting?

Thanks @Sigri44 for the console screenshot - that's what I was going to ask for next. Nothing there looks related to this failure though unfortunately.

You could also check the console of the background process for errors though - there might be something more useful there.

On Firefox, you can check this by navigating to "Add-Ons", clicking the gear menu to the right of "Manage Your Extensions", clicking "Debug Add-ons", then clicking the "Inspect" button next to MetaMask.

On Chrome, you can check this by going to chrome://extensions/, and clicking "background page" under "inspect views" on the MetaMask extension.

I'm having the same problem, I've noticed it for the past 4-5 days, so I'm assuming since the Dec 10th update. MM hangs on many different actions. Swapping on Uniswap, or staking, pretty much anything that creates a tx it will popup straight to spinning wheel. If I click off MM and then click the icon the tx will be there and can be executed. It pretty much goes to spinning wheel with any interaction that involves input. Using the same tx as mentioned, if I go to manually set the gas, when I click 'save' it will go to spinning wheel. If I click off mm and then back in by clicking the icon it will be at the next correct screen.

The same here, often got stuck on the confirm / reject screen of a transaction. Didn't matter which I've clicked, it went into spinning mode and never finished. Firefox reload and reopen of the Metamask sometimes helped, but not always, had to click around and after multiple tries it got it unfrozen.

We are currently investigating potential causes and could range anywhere from network issues to disk usage space. Could anyone with the issue please provide general additional information other than "I have the same issue", such as how is your general network connection (stable, unstable, vpn usage)? Is there adequate harddrive space left on your computer? RAM capacity?

For tech savvy reporters, can you output the background storage quota? The path in Firefox would be to Debug the addon > Inspect > in the console, type:

navigator.storage.estimate().then(function(estimate) {
      console.log((estimate.usage / estimate.quota * 100).toFixed(2));
});

This will give a percentage of the usage of the storage api. or

navigator.storage.estimate().then((data) => console.log(data));

to get the whole object

If txs are the issue, please provide the exact tx params details, we are looking for info on the data field if it's tx's involving contracts and issues with validations with the transaction params. You can omit the sensitive data such as your address.

Im having the same issue with MM. The issue is mainly with chrome/Firefox. Tried a long time to move the eth from the meta wallet, but anything involving a tx it will popup straight to spinning wheel and stays there. The mobile app works fine though. Tx went thru smoothly. tried reinstalling the meta by importing with seed. but same spinning wheel issue is happening. Now I have been logged out of the meta completely. Unable to Import Metamask account

I'm having the same problem, I've noticed it for the past 4-5 days, so I'm assuming since the Dec 10th update. MM hangs on many different actions. Swapping on Uniswap, or staking, pretty much anything that creates a tx it will popup straight to spinning wheel. If I click off MM and then click the icon the tx will be there and can be executed. It pretty much goes to spinning wheel with any interaction that involves input. Using the same tx as mentioned, if I go to manually set the gas, when I click 'save' it will go to spinning wheel. If I click off mm and then back in by clicking the icon it will be at the next correct screen.

Yes, same error !

Firefox dont crash, but loader is loading infinitely. In extensions bar AND when launch MM in "fullscreen", same error. To have it, go to account/contact, and rename 1 or 2 account, loader is infinit :)

We are currently investigating potential causes and could range anywhere from network issues to disk usage space. Could anyone with the issue please provide general additional information other than "I have the same issue", such as how is your general network connection (stable, unstable, vpn usage)? Is there adequate harddrive space left on your computer? RAM capacity?

For tech savvy reporters, can you output the background storage quota? The path in Firefox would be to Debug the addon > Inspect > in the console, type:
navigator.storage.estimate().then(function(estimate) {
      console.log((estimate.usage / estimate.quota * 100).toFixed(2));
});
This will give a percentage of the usage of the storage api. or
navigator.storage.estimate().then((data) => console.log(data));
to get the whole object

If txs are the issue, please provide the exact tx params details, we are looking for info on the data field if it's tx's involving contracts and issues with validations with the transaction params. You can omit the sensitive data such as your address.

Connexion : Fiber link, low ping, Ethernet 1 Gigabit cable for computer, no VPN. Hardware : i5 3770k with 16 Go RAM (no swap or load on computer), SSD with 40% space free and

Thx for quick response !

Free bonus, i have alert firefox for background extension, people use : Ethereum Gas Price Extension ??!

Same issue with never-ending spinner on trying to reinstall with seed phrase.

Firefox for Windows: 84.0 (64-bit) Metamask extension: 8.1.9

how is your general network connection (stable, unstable, vpn usage)? Is there adequate harddrive space left on your computer? RAM capacity?

Network is fine (70Mbps down; 13Mbps up), no VPN. 300GB free disk space 64 GB RAM - currently 50 GB is free.

For tech savvy reporters, can you output the background storage quota?


navigator.storage.estimate().then(function(estimate) {
      console.log((estimate.usage / estimate.quota * 100).toFixed(2));
});
Promise { <state>: "pending" }

0.00
navigator.storage.estimate().then((data) => console.log(data));
Promise { "pending" }

<state>: "pending"

<prototype>: Promise.prototype { … }

{…}

quota: 2147483648

usage: 49152

<prototype>: Object { … }

@Sigri44 What are those screenshots of? Those "doAutoFill" errors appear to be from Bitwarden

I have seen significant performance degradation very recently and today saw it break a dApp.

The dApp in question tries to minimize the size of transactions to avoid issues with high gas usage, including externalizing loops. This means that occasionally a single user action triggers a large number of transactions, and in the observed examples today that number was around 100, usually a little over. (This is the kind of dApp interaction that strongly presses for a need for #4050 or #9130.) The first time I observed this, it was on a machine with 8 GB of RAM running Windows 10 and up-to-date Chrome/MetaMask. The user had ONE tab open in the browser (just the dApp) and no other browser tabs or windows, and no other applications running on the computer except one of the popular video meeting apps used to provide that visibility. Memory usage spiked up close to 100% with about 2GB usage on that Chrome instance, as visible in Windows Task Manager.
It took minutes for the Metamask interface to become responsive. For the first roughly 20 seconds of this it was just a blank gray square with the black shadow (not light gray shadow as many were stacked up on top of each other); then for the rest it was the Metamask fox with an orange spinner: After about a minute the favicon in the upper left converted to a fox icon, but still it just showed the spinner in the main interface: Then the screen partially rendered for a bit: Then content filled in and buttons became labeled: Clicking on Confirm, nothing happened for several seconds. Then the Confirm button was grayed out for about 20 seconds but nothing else happened. Depending on the run, there was then a period of about 20 seconds when the Confirm button came back as active but nothing else happened. Then the loading spinner and overlay was visible for about 40 seconds. Then, that popup disappeared and the user could click on the next one. At a typical rate of 1-1.5 minutes per transaction, the user would be spending two hours clicking MetaMask confirmations. However, after the first few-to-several confirmations, MetaMask just crashed completely. Remaining transaction confirmation dialogues went all-white blank and disappeared from the screen. The dApp had no idea what happened or how to respond; it had to be refreshed and re-entered from then-current state. Several minutes after transaction creation, the history showed a success or few followed by many “transaction dropped” entries. Clicking for details didn’t show much useful information about why: On a subsequent replication run, while the semitransparent white overlay and bars-spinner were visible: I did a right-click and Inspect, but didn’t see any errors: I also found that it was sometimes (but not always) possible to drag the top notification to elsewhere on the screen (sometimes it just was not responsive at all even to window selection/drag attempts). Some time after that, while the first one was still spinning with the overlay, the confirm button would become active on the second. This could be clicked in an effort to parallelize things. In fact, you could lay out more than one and start a little game of whack-a-mole confirming transactions. After a few, but even while several dozen transactions remained awaiting confirmation, the number of remaining transactions disappeared from the bottom, though Confirm was still clickable (example after clicking and Confirm button getting disabled shown here:) After a few confirmations, all the MetaMask windows would in turn go completely white. Then, they would all disappear, along with the DevTools box, though no errors had popped up visible in that DevTools interface, and though Preserve Log had been enabled, none were visible when re-Inspecting after the crash.
I was able to replicate this more than once on a dev machine with 32GB RAM (and a few more things running in the background, but not an especially heavy load).

Reverting to MetaMask 8.1.8 (in a new browser profile) solved the problem. (Too bad there’s not an easy way for most users to do this!) While the delay between confirmation click availabilities was still slower than good UX, I timed being able to complete batch of 80 transaction confirmations in 4 minutes 20 seconds (3.25 seconds each). This was on the same dev machine with the same background loading as tested earlier.

Back in the original profile where the issue was observed, I did a right-click on a MetaMask popup and Inspect, then entered this on the console (while no transactions were pending):

navigator.storage.estimate().then(function(estimate) { console.log((estimate.usage / estimate.quota * 100).toFixed(2)); }); The log produced 0.00. Logging the whole object, quota was 68842330232, usage 2082936, and under usageDetails, indexedDB: 2082936.

I re-triggered a transaction set, this time using a node running locally so network bandwidth could be solidly eliminated as a cause. I observed the same issue. While the big fox-face and spinner were shown, I did a right-click and Inspect Element, then ran the same command in console with the same 0.00 result. I then tried the version with the whole object (navigator.storage.estimate().then((data) => console.log(data));) and this didn’t produce anything for a few minutes. While waiting, I ran both versions in the console of the dApp page, again getting 0.00 (5567/306352447488). Of course, clicking in the browser console cause the MetaMask popups to disappear. I tried clicking on the MetaMask icon with the little 110 on it showing 110 pending transactions, but it took minutes. While waiting for that, I got a response on the navigator storage object in the MetaMask inspector, usage 2089782 over a quota of 69118227254 and all of the usage in indexedDB. Even just clicking the down arrow to expand the object into indexedDB took a couple minutes; the system was pretty unresponsive.

I then turned on the profiler in that DevTools popup for 3 minutes. During this time I re-fetched the navigator storage estimate twice and it was pretty much the same as before, rounding to 0 (2096438/69105552694 and 2096438/69105548598). The profiler looked like this (click to enlarge, then ctrl+scroll to zoom in): In the top red line there’s “Task;” hovering over it reported “Long task took 13.03 s” Clicking on it showed this: The Timer Fired item also took a while: as did Function Call:

I then clicked on initSentry.js:1 to see if I could make out what this “c” function was. Unfortunately it was unreadably minified and even though a source map was detected, I couldn’t get it showing readable Javascript. Pretty-printing the minified file, the function looked like this:

            var c = function() {
                var c = Array.prototype.slice.call(arguments);
                try {
                    a && "function" == typeof a && a.apply(this, arguments);
                    var u = c.map((function(t) {
                        return e(t, n)
                    }
                    ));
                    return t.handleEvent ? t.handleEvent.apply(this, u) : t.apply(this, u)
                } catch (e) {
                    throw s(),
                    o.withScope((function(t) {
                        t.addEventProcessor((function(e) {
                            var t = r.__assign({}, e);
                            return n.mechanism && (i.addExceptionTypeValue(t, void 0, void 0),
                            i.addExceptionMechanism(t, n.mechanism)),
                            t.extra = r.__assign(r.__assign({}, t.extra), {
                                arguments: c
                            }),
                            t
                        }
                        )),
                        o.captureException(e)
                    }
                    )),
                    e
                }
            };

Keep in mind, it’s not this function itself which is the problem, it’s something it calls, as noted in scripting (self) vs. scripting (children).

During this time when the MetaMask popup had finally appeared with the option to confirm 110 transactions, I again checked the navigator.storage()object and it was enough to round to 0 (2130637/69078655693).

initSentry.js as a source of the issue looks a lot like there might be a connection to a recent known-to-be-buggy upgrade nominally fixed in 8.1.9 by #10040. Maybe the fix actually made things worse? #10040 was not listed among the changes for the 8.1.9 release so looking through the PRs associated with that commit is not going to provide a comprehensive view of changes. To complicate things a little bit further, #10040 mixes functional changes with superficial grammatical improvements in console logs and variable renaming that is a refactoring change only (for maintainability). Of the 6 PRs listed on this release, #10034 seems the most relevant (maybe some sort of reentrancy/issue in captureException?).

Back in the profiler, it looks like there’s a cycle between functions, e, l, and an anonymous wrapper, all in background.js:116 (click to enlarge, then ctrl+scroll to zoom in): call tree

Clicking on background.js on the right side of this call tree opened a minified JS file in the browser. Initially, I couldn’t even save the minified background.js file to disk because the CPU was stuck solid at 100% with all those pending transactions still there, blocking further browser action. I clicked X in the upper right corner of the transaction popups and this closed them (along with the devTools which had captured that profile). CPU usage went down a bit and then when I batch rejected all the transactions from the in-browser popup, CPU usage dropped like a rock.

I could then open the saved file in the browser’s sources view and see that it did have content on line 116 as referenced in the call tree. Just before this were comments labeling it as “object-assign © Sindre Sorhus license MIT.” This commit in #9568 (“Add ses lockdown to build system”) changed the version of object.assign being used in some cases from 4.1.0 to 4.1.1 but that’s object.assign rather than object-assign. Looking at that line (background.js:116), it seems to be truncated, with this ending: 1205:[function(e,t,r){arguments[4][859][0].apply(r,arguments)},{dup:859}],1206:[function(e,t,r){(function(e){ background.js then proceeds immediately into an MIT-like license from Microsoft and a line with the contents of that package. On inspection, other package lines seem to have a similar truncation leaving an open function definition at the end of the line. Maybe there is an error in the build process? At this point I ran out of time for further debugging.

All of my test transactions are 0-ETH (gas-only) contract interactions. I don’t think the issue is limitations of the host computer because especially the dev machine is very well-resourced, and changing the MetaMask version on the same machine with the same background loading produced extremely different results, which were very similar to results of a few days earlier. The issue is also clearly not network related because it was still observed when connecting to localhost.

Also, prior to the large set, the dApp triggers a single transaction and that seems to be presented and approved just fine.

If MetaMask were my project and/or I had the authority to do so, I would reissue previously built v8.1.8 as 8.1.10 immediately and send that update out over the usual channels, then get some better analysis and testing in place before another release.

I would change the title to "Dapp-breaking performance degradation" (or use that title if filing as a new Issue) because this isn’t just Firefox; I’m observing it in Chrome [87.0.4280.88 (Official Build) (64-bit) for Windows 10]. Also while I am not 100% confident that what I’m observing is the same as what everyone else is reporting, it seems so similar that it’s likely better to post all the details here than to post it as a separate issue that will be closed as dupe with the details ignored. Finally, I am posting here because this contains a workaround (revert to older MetaMask) that may work for capable others who have reported the issue above.

I think @wbt is onto something here..

With no other extensions enabled, and with a brand new MM 8.1.9, I get this

as soon as I try to start using MM and setting up an account. Sentry fails, and the spinner never stops.

That looks to be the same behaviour I have been getting with the advanced setting toggles.

(As @wbt, I've also encountered the issue around transactions, where you have to close down the window and reopen the extension to be able to proceed with approving a tx, but that might be unrelated.)

Wow that's an incredible amount of detail, thanks @wbt!

Reverting to MetaMask 8.1.8 (in a new browser profile) solved the problem.

How did you revert to v8.1.8 - did you use the bundle on the releases page and install it as an unpacked extension? Did you try installing v8.1.9 the same way, or re-installing v8.1.9 in a fresh browser profile by any means?

I'm wondering if it was the downgrade that helped here, or some other confounding factor. We have been getting sporadic reports of problems along the same lines as the OP on versions v8.1.6-v8.1.8, so I'm not especially confident that republishing v8.1.8 would improve things for most people at this point. If you are experiencing a regression introduced in v8.1.9, it may be distinct from what others are seeing.

That dapp you described sounds unlike anything I've tested with. Could you share which dapp this was (via support if you want a more private channel of communication), or provide a roughly-equivalent JavaScript snippet that produces this behavior as well? I can try creating 0-ETH contract interaction transactions in a loop myself if it's that simple, but the closer I can get to your test case the more likely a successful reproduction is.

I'll start digging through all of this information you've provided! I'll post here if I make any substantial progress.

@johansten Thanks for that screenshot - that led me to a new clue: that Firefox's Enhanced Tracking Protection in "strict" mode might be involved here. I was able to reproduce a freeze locally along with the same error shown in your screenshot, but only after enabling strict mode. Do you use Enhanced Tracking Protection by any chance? If so, are you using strict mode?

@johansten Thanks for that screenshot - that led me to a new clue: that Firefox's Enhanced Tracking Protection in "strict" mode might be involved here. I was able to reproduce a freeze locally along with the same error shown in your screenshot, but only after enabling strict mode. Do you use Enhanced Tracking Protection by any chance? If so, are you using strict mode?

I am using Strict mode ETP, and switching it over to Basic made the problem go away.

Ok guys, for those that want to keep their settings strict everywhere else here is the fix. I did two things. In MM click the 3 dots and go to expand view. Then on that page right click and go to "page info". From there go to permissions. Allow pop ups. I believe this is what fixed it for me. The other thing I did while on the expanded view page was click the shield icon next to the address bar and turn off 'strict'. Tx's are popping up with no spinning wheel now. Yay! Thanks to the other posters who figured it out.

A few responses:

(As @wbt, I've also encountered the issue around transactions, where you have to close down the window and reopen the extension to be able to proceed with approving a tx, but that might be unrelated.)

That's unrelated...MetaMask provides a popup which is a separate application window in addition to the option of clicking on the extension icon to access the confirmation dialog. There are definitely UX design improvements available here, especially when the MetaMask window appears on a different screen under other windows and gets excluded from screenshares, but those are separate issues and neither new nor dApp-breaking.

did you use the bundle on the releases page and install it as an unpacked extension?

Yes.

Did you try installing v8.1.9 the same way, or re-installing v8.1.9 in a fresh browser profile by any means?

Yes, in a fresh browser profile. That fixed it too. I also created a fourth profile and went to metamask.io, then followed the link to the Chrome web store, and installed from there. Unfortunately from a debugging perspective, that worked too. Therefore, I retract what I said above about reverting to 8.1.8 as a potential workaround...it was the new profile that was the workaround.

I then tried to figure out what differences there may be between the profiles. I keep my Chrome pretty vanilla so it seems unlikely to have many complicating factors. In any of the new profiles, going to the Extensions list, I see just MetaMask, Google Docs Offline, a Token Signing extension I can't disable, and under Chrome Apps it's Docs, Sheets, and Slides. The primary profile has the same set at the same versions and only one additional extension, "Blank New Tab Page" 1.0 (which makes it even more 'vanilla' than Google does, from a UX perspective). Disabling that and reloading the dApp gave me the same bad results reported above. However, from the Manage Extensions page, I could click "background page" next to "Inspect views" for Metamask and I did see a couple errors there: The first one appeared near the start of when the big batch of transactions was getting set up:

Error: write after end, at initSentry.js:8 at background.js:116 at t.exports.b.write (background.js:116) at t.exports.m (background.js:116) at h (background.js:34) at t.exports.a.emit (background.js:34) at _ (background.js:116) at w (background.js:116) at t.exports.v.push (background.js:116) at s._write (background.js:110) at v (background.js:116) at background.js:116 at s.b.write (background.js:116) at a.o (background.js:116) at h (background.js:34) at a.emit (background.js:34) at c. (background.js:51) at h (background.js:34) at c.a.emit (background.js:34) at c.request (background.js:51) at r (background.js:51) at background.js:116 at m.run (background.js:116) at p (background.js:116) at c (initSentry.js:1)

and I think the second was after I clicked the first Confirm in the batch, also on initSentry.js:8, expanded:

Error: write after end at background.js:116 at t.exports.b.write (background.js:116) at t.exports.m (background.js:116) at h (background.js:34) at t.exports.a.emit (background.js:34) at _ (background.js:116) at w (background.js:116) at t.exports.v.push (background.js:116) at s.write (background.js:110) at v (background.js:116) at background.js:116 at s.b.write (background.js:116) at f.m (background.js:116) at h (background.js:34) at f.a.emit (background.js:34) at (background.js:116) at w (background.js:116) at f.v.push (background.js:116) at background.js:103 at a._handle (background.js:103)

When expanding the latter error object, I can trace the following:

(anonymous) @ initSentry.js:8 (anonymous) @ background.js:1 (anonymous) @ background.js:116 t @ background.js:116 (anonymous) @ background.js:116 t @ background.js:116 g @ background.js:51 h @ background.js:34 a.emit @ background.js:34 (anonymous) @ background.js:116 b.write @ background.js:116 m @ background.js:116 h @ background.js:34 a.emit @ background.js:34 _ @ background.js:116 w @ background.js:116 v.push @ background.js:116 write @ background.js:110 v @ background.js:116 (anonymous) @ background.js:116 b.write @ background.js:116 m @ background.js:116 h @ background.js:34 a.emit @ background.js:34 @ background.js:116 w @ background.js:116 v.push @ background.js:116 (anonymous) @ background.js:103 _handle @ background.js:103 async function (async)
handle @ background.js:103 handle @ background.js:103 write @ background.js:103 v @ background.js:116 (anonymous) @ background.js:116 b.write @ background.js:116 m @ background.js:116 h @ background.js:34 a.emit @ background.js:34 @ background.js:116 w @ background.js:116 v.push @ background.js:116 write @ background.js:110 v @ background.js:116 (anonymous) @ background.js:116 b.write @ background.js:116 m @ background.js:116 h @ background.js:34 a.emit @ background.js:34 @ background.js:116 w @ background.js:116 v.push @ background.js:116 _onMessage @ background.js:80 (anonymous) @ background.js:80

In that sequence I noticed at least one popup with an ""Error: [ethjs-query] while formatting outputs from RPC '{"value":{"code":-32603,"data":{"code":-32000,"message":"nonce too low"}}}'"" and another reporting "Transaction NaN confirmed! View on etherscan" and a bunch of transactions got dropped, with just a couple remaining at the end. I don't know how to explain the "Transaction NaN" but should note that if you try to spread out multiple copies of the MetaMask notification window for the whack-a-mole I described earlier, it sometimes results in transactions failing "nonce too low" if you don't click "confirm" in the same order in which the transactions are generated. In most cases you won't get this issue because instead of 100+ separate popups for separate transactions, it's actually 100+ copies of the same popup with the same stack of transactions, so if you click Confirm in several windows it's confirming the same top transaction multiple times rather than confirming multiple different transactions. The "nonce too low" error is expected when you click in a window that says "Reject " transactions where N is not the lowest number of all Metamask popup windows, assuming the dApp does not generate new transactions after the successful completion of earlier ones until at least after the full set is completed. Therefore you kind of have to wait for one transaction submission to complete before proceeding to the next. I don't know anybody who wants to spend hours clicking and waiting to accomplish what should be one simple task (and would be, with #4050 or #9130 +).

In trying to replicate this a few more times to try to confirm timing details on the appearance of the error, it started working regularly. I then suspected that other extension, re-enabled it and refreshed the dApp, re-triggered the transaction batch, and was back to the very long load time to set up.

I then switched to the profile in which I'd installed MetaMask from the Chrome web store and added that extension. I refreshed the dApp page and retriggered the transaction set, and things worked fine. I then closed out of that profile's window completely, re-opened it, and got a notice from Chrome that the extension had changed my new tab page:

I chose "Keep it." (Maybe the change about enabling/disabling that extension doesn't take effect until you open a new tab?) I returned to the dApp, retriggered the set of transactions, and saw the incorrect behavior reported here.

I then switched to the profile with 8.1.8, installed that extension, opened a new tab and clicked "Keep it," and navigated to the dApp, triggering the transaction batch; things worked well. I closed all tabs on that profile's window (but maybe not the devTools window inspecting the MM background page), reopened the profile, re-navigated to the dApp. Again, things worked pretty well. I then closed the window for that profile including the DevTools, reopened it, and repeated the triggering. It was then showing the bad behavior, being super slow. This is further evidence that reverting to 8.1.8 is unlikely to be an effective solution. (On the plus side, I feel slightly better about not having been able to diagnose a cause from reviewing the 8.1.8 to 8.1.9 diff.)

I don't think the user on whose machine I initially observed this issue has that particular extension installed. However, I recommend installing that extension and then completely restarting the browser profile to help with reproduction testing. Also, it is expected behavior that MetaMask would play nicely with other extensions, especially simple ones that seem unrelated to web3/blockchains.

a new clue: that Firefox's Enhanced Tracking Protection in "strict" mode might be involved here.

I am using Strict mode ETP, and switching it over to Basic made the problem go away.

...Allow pop ups...

That may be an issue, but not the cause of what I observed in Chrome. @Exaptcrypto doesn't say but I think is using Firefox based on the "page info" entry in the right-click menu, which Chrome doesn't have. However, copying the URL from that and manually adding it as "allow popups" in Chrome permissions (which it correctly detects as the MetaMask extension) didn't solve the primary performance issue for me. It somewhat delayed the number of times I could click confirm before the full-out crash, but that might've been coincidence.

That dapp you described sounds unlike anything I've tested with. Could you share which dapp this was (via support if you want a more private channel of communication), or provide a roughly-equivalent JavaScript snippet that produces this behavior as well? I can try creating 0-ETH contract interaction transactions in a loop myself if it's that simple, but the closer I can get to your test case the more likely a successful reproduction is.

I don't have time to develop a full response, but here would be my strategy to produce a minimal example: create a "Counter.sol" smart contract with a public uint and a single function increment() which adds 1 to it and emits an event with the new value. Then make a button which triggers 100 increment() transactions, calling that smart contract function in a loop. Assuming the same issue is visible there, that's probably be a fair minimal example.

Hi guys, yes I was using firefox.

Sad to say that the issues are back. Spinning wheel on any input. Click swap in uni, popup spinning wheel. Click off meta and then click on extension, tx will be there. Click confirm.... spinning wheel. Click off and back on its already sent. Same with manually changing gas.

Is there a way to go back to the old version? This actually just cost me a lot of money in an initial offering.

On Sun, Dec 20, 2020 at 1:28 AM wbt notifications@github.com wrote:

A few responses:

(As @wbt https://github.com/wbt, I've also encountered the issue around transactions, where you have to close down the window and reopen the extension to be able to proceed with approving a tx, but that might be unrelated.)

That's unrelated...MetaMask provides a popup which is a separate application window in addition to the option of clicking on the extension icon to access the confirmation dialog. There are definitely UX design improvements available here, especially when the MetaMask window appears on a different screen under other windows and gets excluded from screenshares, but those are separate issues and neither new nor dApp-breaking.

did you use the bundle on the releases page and install it as an unpacked extension?

Yes.

Did you try installing v8.1.9 the same way, or re-installing v8.1.9 in a fresh browser profile by any means?

Yes, in a fresh browser profile. That fixed it too. I also created a fourth profile and went to metamask.io, then followed the link https://chrome.google.com/webstore/detail/metamask/nkbihfbeogaeaoehlefnkodbefgpgknn/related?hl=en to the Chrome web store, and installed from there. Unfortunately from a debugging perspective, that worked too. Therefore, I retract what I said above about reverting to 8.1.8 as a potential workaround...it was the new profile that was the workaround.

I then tried to figure out what differences there may be between the profiles. I keep my Chrome pretty vanilla so it seems unlikely to have many complicating factors. In any of the new profiles, going to the Extensions list, I see just MetaMask, Google Docs Offline, a Token Signing extension I can't disable, and under Chrome Apps it's Docs, Sheets, and Slides. The primary profile has the same set at the same versions and only one additional extension, "Blank New Tab Page" https://chrome.google.com/webstore/detail/blank-new-tab-page/jaadjnlkjnhohljficgoddcjmndjfdmi 1.0 (which makes it even more 'vanilla' than Google does, from a UX perspective). Disabling that and reloading the dApp gave me the same bad results reported above. However, from the Manage Extensions page, I could click "background page" next to "Inspect views" for Metamask and I did see a couple errors there: [image: image] https://user-images.githubusercontent.com/563406/102695231-eaf95800-41f3-11eb-89be-76bee1c3e750.png The first one appeared near the start of when the big batch of transactions was getting set up:

Error: write after end, at initSentry.js:8 at background.js:116 at t.exports.b.write (background.js:116) at t.exports.m (background.js:116) at h (background.js:34) at t.exports.a.emit (background.js:34) at _ (background.js:116) at w (background.js:116) at t.exports.v.push (background.js:116) at s._write (background.js:110) at v (background.js:116) at background.js:116 at s.b.write (background.js:116) at a.o (background.js:116) at h (background.js:34) at a.emit (background.js:34) at c. (background.js:51) at h (background.js:34) at c.a.emit (background.js:34) at c.request (background.js:51) at r (background.js:51) at background.js:116 at m.run (background.js:116) at p (background.js:116) at c (initSentry.js:1)

and I think the second was after I clicked the first Confirm in the batch, also on initSentry.js:8, expanded:

Error: write after end at background.js:116 at t.exports.b.write (background.js:116) at t.exports.m (background.js:116) at h (background.js:34) at t.exports.a.emit (background.js:34) at _ (background.js:116) at w (background.js:116) at t.exports.v.push (background.js:116) at s.write (background.js:110) at v (background.js:116) at background.js:116 at s.b.write (background.js:116) at f.m (background.js:116) at h (background.js:34) at f.a.emit (background.js:34) at (background.js:116) at w (background.js:116) at f.v.push (background.js:116) at background.js:103 at a._handle (background.js:103)

When expanding the latter error object, I can trace the following:

(anonymous) @ initSentry.js:8 (anonymous) @ background.js:1 (anonymous) @ background.js:116 t @ background.js:116 (anonymous) @ background.js:116 t @ background.js:116 g @ background.js:51 h @ background.js:34 a.emit @ background.js:34 (anonymous) @ background.js:116 b.write @ background.js:116 m @ background.js:116 h @ background.js:34 a.emit @ background.js:34 _ @ background.js:116 w @ background.js:116 v.push @ background.js:116 write @ background.js:110 v @ background.js:116 (anonymous) @ background.js:116 b.write @ background.js:116 m @ background.js:116 h @ background.js:34 a.emit @ background.js:34 @ background.js:116 w @ background.js:116 v.push @ background.js:116 (anonymous) @ background.js:103 _handle @ background.js:103 async function (async) handle @ background.js:103 handle @ background.js:103 write @ background.js:103 v @ background.js:116 (anonymous) @ background.js:116 b.write @ background.js:116 m @ background.js:116 h @ background.js:34 a.emit @ background.js:34 @ background.js:116 w @ background.js:116 v.push @ background.js:116 write @ background.js:110 v @ background.js:116 (anonymous) @ background.js:116 b.write @ background.js:116 m @ background.js:116 h @ background.js:34 a.emit @ background.js:34 @ background.js:116 w @ background.js:116 v.push @ background.js:116 _onMessage @ background.js:80 (anonymous) @ background.js:80

In that sequence I noticed at least one popup with an ""Error: [ethjs-query] while formatting outputs from RPC '{"value":{"code":-32603,"data":{"code":-32000,"message":"nonce too low"}}}'"" and another reporting "Transaction NaN confirmed! View on etherscan" and a bunch of transactions got dropped, with just a couple remaining at the end. I don't know how to explain the "Transaction NaN" but should note that if you try to spread out multiple copies of the MetaMask notification window for the whack-a-mole I described earlier, it sometimes results in transactions failing "nonce too low" if you don't click "confirm" in the same order in which the transactions are generated. In most cases you won't get this issue because instead of 100+ separate popups for separate transactions, it's actually 100+ copies of the same popup with the same stack of transactions, so if you click Confirm in several windows it's confirming the same top transaction multiple times rather than confirming multiple different transactions. The "nonce too low" error is expected when you click in a window that says "Reject " transactions where N is not the lowest number of all Metamask popup windows, assuming the dApp does not generate new transactions after the successful completion of earlier ones until at least after the full set is completed. Therefore you kind of have to wait for one transaction submission to complete before proceeding to the next. I don't know anybody who wants to spend hours clicking and waiting to accomplish what should be one simple task (and would be, with #4050 https://github.com/MetaMask/metamask-extension/issues/4050 or #9130 https://github.com/MetaMask/metamask-extension/pull/9130 +).

In trying to replicate this a few more times to try to confirm timing details on the appearance of the error, it started working regularly. I then suspected that other extension, re-enabled it and refreshed the dApp, re-triggered the transaction batch, and was back to the very long load time to set up.

I then switched to the profile in which I'd installed MetaMask from the Chrome web store and added that extension. I refreshed the dApp page and retriggered the transaction set, and things worked fine. I then closed out of that profile's window completely, re-opened it, and got a notice from Chrome that the extension had changed my new tab page: [image: image] https://user-images.githubusercontent.com/563406/102696143-1f701280-41fa-11eb-9b14-384fea1f739a.png

I chose "Keep it." (Maybe the change about enabling/disabling that extension doesn't take effect until you open a new tab?) I returned to the dApp, retriggered the set of transactions, and saw the incorrect behavior reported here.

I then switched to the profile with 8.1.8, installed that extension, opened a new tab and clicked "Keep it," and navigated to the dApp, triggering the transaction batch; things worked well. I closed all tabs on that profile's window (but maybe not the devTools window inspecting the MM background page), reopened the profile, re-navigated to the dApp. Again, things worked pretty well. I then closed the window for that profile including the DevTools, reopened it, and repeated the triggering. It was then showing the bad behavior, being super slow. This is further evidence that reverting to 8.1.8 is unlikely to be an effective solution. (On the plus side, I feel slightly better about not having been able to diagnose a cause from reviewing the 8.1.8 to 8.1.9 diff.)

I don't think the user on whose machine I initially observed this issue has that particular extension installed. However, I recommend installing that extension and then completely restarting the browser profile to help with reproduction testing. Also, it is expected behavior that MetaMask would play nicely with other extensions, especially simple ones that seem unrelated to web3/blockchains.

a new clue: that Firefox's Enhanced Tracking Protection in "strict" mode might be involved here.

I am using Strict mode ETP, and switching it over to Basic made the problem go away.

...Allow pop ups...

That may be an issue, but not the cause of what I observed in Chrome. @Exaptcrypto https://github.com/Exaptcrypto doesn't say but I think is using Firefox based on the "page info" entry in the right-click menu, which Chrome doesn't have. However, copying the URL from that and manually adding it as "allow popups" in Chrome permissions (which it correctly detects as the MetaMask extension) didn't solve the primary performance issue for me. It somewhat delayed the number of times I could click confirm before the full-out crash, but that might've been coincidence.

That dapp you described sounds unlike anything I've tested with. Could you share which dapp this was (via support if you want a more private channel of communication), or provide a roughly-equivalent JavaScript snippet that produces this behavior as well? I can try creating 0-ETH contract interaction transactions in a loop myself if it's that simple, but the closer I can get to your test case the more likely a successful reproduction is.

I don't have time to develop a full response, but here would be my strategy to produce a minimal example: create a "Counter.sol" smart contract with a public uint and a single function increment() which adds 1 to it and emits an event with the new value. Then make a button which triggers 100 increment() transactions, calling that smart contract function in a loop. Assuming the same issue is visible there, that's probably be a fair minimal example.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MetaMask/metamask-extension/issues/10097#issuecomment-748508536, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASFHCS5XVBMWNZ7Q2TIKDYDSVTWGNANCNFSM4U7KSTDQ .

Literally anything, I just added a new token.... spinning wheel. However 1 difference with adding the token is that clicking off and then opening didnt work. It never added the token. With every other input = wheel, the action I wanted to happen happened immediately despite the unnecessary spinning wheel of death.

On Sun, Dec 20, 2020 at 2:18 AM Expat Crypto expatcrypto@gmail.com wrote:

Hi guys, yes I was using firefox.

Sad to say that the issues are back. Spinning wheel on any input. Click swap in uni, popup spinning wheel. Click off meta and then click on extension, tx will be there. Click confirm.... spinning wheel. Click off and back on its already sent. Same with manually changing gas.

Is there a way to go back to the old version? This actually just cost me a lot of money in an initial offering.

On Sun, Dec 20, 2020 at 1:28 AM wbt notifications@github.com wrote:

A few responses:

(As @wbt https://github.com/wbt, I've also encountered the issue around transactions, where you have to close down the window and reopen the extension to be able to proceed with approving a tx, but that might be unrelated.)

That's unrelated...MetaMask provides a popup which is a separate application window in addition to the option of clicking on the extension icon to access the confirmation dialog. There are definitely UX design improvements available here, especially when the MetaMask window appears on a different screen under other windows and gets excluded from screenshares, but those are separate issues and neither new nor dApp-breaking.

did you use the bundle on the releases page and install it as an unpacked extension?

Yes.

Did you try installing v8.1.9 the same way, or re-installing v8.1.9 in a fresh browser profile by any means?

Yes, in a fresh browser profile. That fixed it too. I also created a fourth profile and went to metamask.io, then followed the link https://chrome.google.com/webstore/detail/metamask/nkbihfbeogaeaoehlefnkodbefgpgknn/related?hl=en to the Chrome web store, and installed from there. Unfortunately from a debugging perspective, that worked too. Therefore, I retract what I said above about reverting to 8.1.8 as a potential workaround...it was the new profile that was the workaround.

I then tried to figure out what differences there may be between the profiles. I keep my Chrome pretty vanilla so it seems unlikely to have many complicating factors. In any of the new profiles, going to the Extensions list, I see just MetaMask, Google Docs Offline, a Token Signing extension I can't disable, and under Chrome Apps it's Docs, Sheets, and Slides. The primary profile has the same set at the same versions and only one additional extension, "Blank New Tab Page" https://chrome.google.com/webstore/detail/blank-new-tab-page/jaadjnlkjnhohljficgoddcjmndjfdmi 1.0 (which makes it even more 'vanilla' than Google does, from a UX perspective). Disabling that and reloading the dApp gave me the same bad results reported above. However, from the Manage Extensions page, I could click "background page" next to "Inspect views" for Metamask and I did see a couple errors there: [image: image] https://user-images.githubusercontent.com/563406/102695231-eaf95800-41f3-11eb-89be-76bee1c3e750.png The first one appeared near the start of when the big batch of transactions was getting set up:

Error: write after end, at initSentry.js:8 at background.js:116 at t.exports.b.write (background.js:116) at t.exports.m (background.js:116) at h (background.js:34) at t.exports.a.emit (background.js:34) at _ (background.js:116) at w (background.js:116) at t.exports.v.push (background.js:116) at s._write (background.js:110) at v (background.js:116) at background.js:116 at s.b.write (background.js:116) at a.o (background.js:116) at h (background.js:34) at a.emit (background.js:34) at c. (background.js:51) at h (background.js:34) at c.a.emit (background.js:34) at c.request (background.js:51) at r (background.js:51) at background.js:116 at m.run (background.js:116) at p (background.js:116) at c (initSentry.js:1)

and I think the second was after I clicked the first Confirm in the batch, also on initSentry.js:8, expanded:

Error: write after end at background.js:116 at t.exports.b.write (background.js:116) at t.exports.m (background.js:116) at h (background.js:34) at t.exports.a.emit (background.js:34) at _ (background.js:116) at w (background.js:116) at t.exports.v.push (background.js:116) at s.write (background.js:110) at v (background.js:116) at background.js:116 at s.b.write (background.js:116) at f.m (background.js:116) at h (background.js:34) at f.a.emit (background.js:34) at (background.js:116) at w (background.js:116) at f.v.push (background.js:116) at background.js:103 at a._handle (background.js:103)

When expanding the latter error object, I can trace the following:

(anonymous) @ initSentry.js:8 (anonymous) @ background.js:1 (anonymous) @ background.js:116 t @ background.js:116 (anonymous) @ background.js:116 t @ background.js:116 g @ background.js:51 h @ background.js:34 a.emit @ background.js:34 (anonymous) @ background.js:116 b.write @ background.js:116 m @ background.js:116 h @ background.js:34 a.emit @ background.js:34 _ @ background.js:116 w @ background.js:116 v.push @ background.js:116 write @ background.js:110 v @ background.js:116 (anonymous) @ background.js:116 b.write @ background.js:116 m @ background.js:116 h @ background.js:34 a.emit @ background.js:34 @ background.js:116 w @ background.js:116 v.push @ background.js:116 (anonymous) @ background.js:103 _handle @ background.js:103 async function (async) handle @ background.js:103 handle @ background.js:103 write @ background.js:103 v @ background.js:116 (anonymous) @ background.js:116 b.write @ background.js:116 m @ background.js:116 h @ background.js:34 a.emit @ background.js:34 @ background.js:116 w @ background.js:116 v.push @ background.js:116 write @ background.js:110 v @ background.js:116 (anonymous) @ background.js:116 b.write @ background.js:116 m @ background.js:116 h @ background.js:34 a.emit @ background.js:34 @ background.js:116 w @ background.js:116 v.push @ background.js:116 _onMessage @ background.js:80 (anonymous) @ background.js:80

In that sequence I noticed at least one popup with an ""Error: [ethjs-query] while formatting outputs from RPC '{"value":{"code":-32603,"data":{"code":-32000,"message":"nonce too low"}}}'"" and another reporting "Transaction NaN confirmed! View on etherscan" and a bunch of transactions got dropped, with just a couple remaining at the end. I don't know how to explain the "Transaction NaN" but should note that if you try to spread out multiple copies of the MetaMask notification window for the whack-a-mole I described earlier, it sometimes results in transactions failing "nonce too low" if you don't click "confirm" in the same order in which the transactions are generated. In most cases you won't get this issue because instead of 100+ separate popups for separate transactions, it's actually 100+ copies of the same popup with the same stack of transactions, so if you click Confirm in several windows it's confirming the same top transaction multiple times rather than confirming multiple different transactions. The "nonce too low" error is expected when you click in a window that says "Reject " transactions where N is not the lowest number of all Metamask popup windows, assuming the dApp does not generate new transactions after the successful completion of earlier ones until at least after the full set is completed. Therefore you kind of have to wait for one transaction submission to complete before proceeding to the next. I don't know anybody who wants to spend hours clicking and waiting to accomplish what should be one simple task (and would be, with #4050 https://github.com/MetaMask/metamask-extension/issues/4050 or #9130 https://github.com/MetaMask/metamask-extension/pull/9130 +).

In trying to replicate this a few more times to try to confirm timing details on the appearance of the error, it started working regularly. I then suspected that other extension, re-enabled it and refreshed the dApp, re-triggered the transaction batch, and was back to the very long load time to set up.

I then switched to the profile in which I'd installed MetaMask from the Chrome web store and added that extension. I refreshed the dApp page and retriggered the transaction set, and things worked fine. I then closed out of that profile's window completely, re-opened it, and got a notice from Chrome that the extension had changed my new tab page: [image: image] https://user-images.githubusercontent.com/563406/102696143-1f701280-41fa-11eb-9b14-384fea1f739a.png

I chose "Keep it." (Maybe the change about enabling/disabling that extension doesn't take effect until you open a new tab?) I returned to the dApp, retriggered the set of transactions, and saw the incorrect behavior reported here.

I then switched to the profile with 8.1.8, installed that extension, opened a new tab and clicked "Keep it," and navigated to the dApp, triggering the transaction batch; things worked well. I closed all tabs on that profile's window (but maybe not the devTools window inspecting the MM background page), reopened the profile, re-navigated to the dApp. Again, things worked pretty well. I then closed the window for that profile including the DevTools, reopened it, and repeated the triggering. It was then showing the bad behavior, being super slow. This is further evidence that reverting to 8.1.8 is unlikely to be an effective solution. (On the plus side, I feel slightly better about not having been able to diagnose a cause from reviewing the 8.1.8 to 8.1.9 diff.)

I don't think the user on whose machine I initially observed this issue has that particular extension installed. However, I recommend installing that extension and then completely restarting the browser profile to help with reproduction testing. Also, it is expected behavior that MetaMask would play nicely with other extensions, especially simple ones that seem unrelated to web3/blockchains.

a new clue: that Firefox's Enhanced Tracking Protection in "strict" mode might be involved here.

I am using Strict mode ETP, and switching it over to Basic made the problem go away.

...Allow pop ups...

That may be an issue, but not the cause of what I observed in Chrome. @Exaptcrypto https://github.com/Exaptcrypto doesn't say but I think is using Firefox based on the "page info" entry in the right-click menu, which Chrome doesn't have. However, copying the URL from that and manually adding it as "allow popups" in Chrome permissions (which it correctly detects as the MetaMask extension) didn't solve the primary performance issue for me. It somewhat delayed the number of times I could click confirm before the full-out crash, but that might've been coincidence.

That dapp you described sounds unlike anything I've tested with. Could you share which dapp this was (via support if you want a more private channel of communication), or provide a roughly-equivalent JavaScript snippet that produces this behavior as well? I can try creating 0-ETH contract interaction transactions in a loop myself if it's that simple, but the closer I can get to your test case the more likely a successful reproduction is.

I don't have time to develop a full response, but here would be my strategy to produce a minimal example: create a "Counter.sol" smart contract with a public uint and a single function increment() which adds 1 to it and emits an event with the new value. Then make a button which triggers 100 increment() transactions, calling that smart contract function in a loop. Assuming the same issue is visible there, that's probably be a fair minimal example.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MetaMask/metamask-extension/issues/10097#issuecomment-748508536, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASFHCS5XVBMWNZ7Q2TIKDYDSVTWGNANCNFSM4U7KSTDQ .

@Sigri44 What are those screenshots of? Those "doAutoFill" errors appear to be from Bitwarden

Screenshot from Metamask debug.... Yes i have bitwarden !

@Exaptcrypto If you want an easy way to revert to an earlier version, weigh in on the impacts at #10105 dedicated to that topic.

I think it's the metametrics that is completely breaking metamask in firefox. Couldn't even turn it off with out first allowing sentry.io, segment.io, in all protection services. Then I could finally toggle "metametrics" off and things are working again.

We believe that this issue is resolved with version 8.1.10. We were not handling a network error correctly, see this comment for details: https://github.com/MetaMask/metamask-extension/issues/10114#issuecomment-752310337

@johansten or someone else, can you please confirm that you have version 8.1.10 on Firefox (Settings -> About) and that it's working?

I've got the new version and it does seem to be working smoothly now.

On Tue, Jan 5, 2021 at 11:24 PM Erik Marks notifications@github.com wrote:

We believe that this issue is resolved with version 8.1.10. We were not handling a network error correctly, see this comment for details: #10114 (comment) https://github.com/MetaMask/metamask-extension/issues/10114#issuecomment-752310337

@johansten https://github.com/johansten or someone else, can you please confirm that you have version 8.1.10 on Firefox (Settings -> About) and that it's working?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MetaMask/metamask-extension/issues/10097#issuecomment-754742331, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASFHCS3COIWSJ7V7H2OUK4DSYM4MHANCNFSM4U7KSTDQ .

Thank you, @Exaptcrypto.

We've had multiple reports now on this and related issues that these freezes are resolved. JSON wallet imports may still be a problem, but if that's the case, please use issue #10113.

I will close this issue now, but please do reach out if you have any further problems.

MetaMask / metamask-extension

Metamask freezing in Firefox and v8.1.6-8.1.9 #10097