Metamask-extension: Supported browser versions

[Gudahtt]

We should be explicit about which browser versions we support, and take steps to ensure we remain compatible.

Currently we state on our website that we are compatible with Chrome, Firefox, and Brave, but we don't specify any minimum required browser versions. Opera is listed as well, but that version is very outdated. We don't regularly test which browsers the application works on either, relying instead upon bug reports for compatibility with older browsers.

There was a previous issue for documenting which browsers we support (#3343), but that was closed with an adjustment of our Babel configuration file to support all browser versions with at least 0.25% global usage (according to browserlist), excluding IE 11 and Opera Mini. However, this includes some _very old_ browser versions, more than we'd care to support in practice.

Instead we should document explicitly which browsers we support, and add tests to ensure we stay compatible (perhaps to run nightly, so we don't overly burden CI). Then we can get rid of the Babel transformations and polyfills we no longer need. We should also update the manifests to state the minimum browser version, so users don't accidentally install the extension on an unsupported browser.

Steps:

• [ ] Choose minimum supported browser versions
• [ ] Document the supported browser versions
• [x] Remove Babel transformations and polyfills used for compatibility with unsupported browsers
• [ ] Add nightly tests for minimum supported browser versions
• [x] Update manifests to include minimum browser version

[Gudahtt]

Choose minimum supported browser versions
Here are the factors to consider that I've thought of so far

• User impact
  
  
  
  • How many users would be affected?
  
  
  • How many users would be unable or unwilling to switch to a supported browser?
  
  
• Support / Quality Assurance
  
  
  
  • More browser versions to test means more QA and support
  
  
  • We could have a two-tiered system, where "tier 1" platforms (e.g. last 2 versions of each browser) get are included in typical QA efforts, but for "tier 2" platforms (e.g. older versions) we rely upon bug reports from users. It would still be more work than dropping support though.
  
  
• Development / Maintenance
  
  
  
  • Transformations and polyfills are required to support features we use on older platforms
  
  
  • Complicates build process
  
  
  • Slows down build process
  
  
  • Increases final bundle size
  
  
  • Many of the tools and libraries we use may not work on older platforms. Taking care to ensure things are compatible takes time, and is often not considered by new contributors
  
  
  • Certain new JavaScript features come with improvements to the development experience (e.g. async stack traces). Supporting older browsers might mean not benefiting from these improvements
  
  
  • Certain new features might be easier/faster to build if we didn't have to worry about supporting older platforms
  
  
• Product
  
  
  
  • Certain new JavaScript features come with performance improvements
  
  
• Security
  
  
  
  • Older browsers generally aren't secure. Supporting older browsers could be seen as encouraging their use, or at least enabling it. Maybe that's something we shouldn't do on principle.
  
  
  • There may be additional security implications we don't know about
  
  

I don't know the answer to many of those questions. I do have one strong preference though: that we only support browser versions with async / await support. The async-to-generator transformation required to support browsers without async functions means that we won't have async strack traces, even on newer browsers. Async strack traces can be incredibly useful for certain errors. Using async / await comes with some nifty performance enhancements too.

So that puts us at Chrome 55 and Firefox 52.

That still leaves us with a number of Babel transformations though; 6 for Firefox and one for Chrome. To get zero preset-env transformations, we need to go to Chrome 58 and Firefox 53.

Next I'm going to test the extension on older browsers, to get a sense for whether it works correctly at the moment. We should probably drop support for any older browsers that are already incompatible.

[Gudahtt]

Our usage metrics indicate that nearly everybody is using versions of Firefox >= 53, or Chromium > 58 (where 'Chromium' includes Google Chrome, Chromium, and any browsers based off of Chromium). Out of ~380k visits recorded since July 1st, a single visit was made using Firefox 50, and 176 were unable to be identified (0.047% of visits at worst, assuming all the unknown visits were from older versions).

Overall it looks like ~93.7% of visits were made using most recent 2 versions or greater (e.g. beta/canary or development builds) of Chromium or Firefox.

[Gudahtt]

Firefox has an extended support release, which is currently at version 60. There is no equivalent for Chromium - they only support the latest release.

If we wanted to adopt a more aggressive policy of only supporting browser versions that are actively maintained, I'd suggest we set the Firefox ESR release as the minimum for Firefox, and take the last 2 version for Chromium. That would include between 94-96% of traffic, according to the usage statistics I collected earlier. That still leaves 4% of users on outdated browsers though - that's not insignificant.

[Gudahtt]

The minimum versions have been set to Firefox 53 and Chromium 58 for now (in #6877 and #6812).

Warnings were discovered from addons-linter that indicate we're using extension APIs only available in Firefox 56, so we need to at least bump to that version as our minimum. Though I'm still of the opinion that Firefox 60 is a better choice, given the long-term support and the lack of users on older versions.

I was unable to find any examples of us using Chrome API's or Web APIs that aren't supported by Chrome 58. The only compelling reason I could find so far to set a higher minimum version is Object rest/spread - bumping the minimum to Chrome 60 would let us drop that Babel transformation.

[bdresser]

@tmashuang @Gudahtt is this close to the finish line?

[Gudahtt]

The current hang-up is automated tests. I had trouble finding a binary for
our minimum chromium version from a trusted source, so I put it aside for
now.

Once the tests are figured out, I think we can add docs and call this done.

On Thu, Aug 15, 2019, 18:42 bobby dresser [e-mail] wrote:

@tmashuang https://github.com/tmashuang @Gudahtt
https://github.com/Gudahtt is this close to the finish line?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MetaMask/metamask-extension/issues/6805?email_source=notifications&email_token=AASYNF276XXDS6CMCH5JWXLQEXEU7A5CNFSM4H543H72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4NCRAI#issuecomment-521808001,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AASYNF52PWF7PJALERPWQ6LQEXEU7ANCNFSM4H543H7Q
.

[leafcutterant]

I hope this is the right place to report this.

MM 7.0+ can be installed only on Firefox 60.0+. Due to this, Firefox forks that haven't progressed to 60.0+ (e.g. Waterfox) can't use the latest MM. Any chance of this changing?

[Gudahtt]

@leafcutterant Sure, this is a good place to discuss this.

I do have some hesitance because we'd like to move to newer minimum versions if possible, to allow ourselves to use newer browser APIs. We also don't generally want to encourage the use of older browsers that aren't getting security updates. But if it doesn't cause us too much trouble and you think there's a legitimate need, we can definitely consider it.

Thanks for bringing Waterfox to our attention - I wasn't aware that this browser existed, or that it was stuck on Firefox 56. From glancing at their issue tracker, it looks like it'll be a while before they're able to update (if ever).

Could you elaborate on why you use Waterfox, or why you think it's important to support? We don't see very many users using Waterfox.

[leafcutterant]

@Gudahtt, sure, thank your for listening!

First of all, let me explain the rationale of using Firefox forks: a few years ago Mozilla started to put limitations on what kind of addons you're able to add to your browser. These limitations grew more and more egregious over time, and the effort needed to hack around them increased. This got to a point where now it's hard-coded in the browser that any addon not downloaded from the Mozilla extension store can't be used. They have exclusive control over what can and cannot be installed in your own browser. Some people are okay with this. I'm definitely not, and I hope that you and most others in crypto feel the same. Centralization is dangerous.

But bls sir wher go now? FF ESR? Thanks, I prefer to get critical fixes on time. FF developer/beta/nightly? I'd rather choose stability. Anyone who wanted to retain the freedom they got used to, but wanted a browser that works, turned to FF forks. Many exist. None are perfect. Waterfox stands out with their hard-line commitment to 1) privacy, 2) user freedom and 3) usability. Almost everything that phones home, sends user data anywhere or aids surveillance has been removed from the code base. Users can modify any setting and install any extensions, even non-WebExt addons, which is a huge boon. It's currently up-to-date to FF 60.9 wrt security. Among FF forks, it is quite up-to-date with the upstream, breaks the least things, and has the largest social following and contributor base if we don't count Tor Browser.

Waterfox matters because it's a libre safe haven. Just like with cryptocurrencies, overall not many people may use it, but its existence is important.

[Gudahtt]

Thanks for explaining! I'm glad to hear that it's still getting security updates. Some of those reasons are certainly compelling.

I'll set the minimum version to 56.2, which should be compatible with "Waterfox Classic" (i.e. the stable version). It looks like we can keep using v56 a while longer without adding any additional transpiling. I'm using 56.2 instead of 56.0 to prevent MetaMask from being installed on Firefox for Android 56.0 (which is missing a feature we use).

I can't make any promises on keeping it here though. When the day comes that we want to use a new browser API, we'll bump up the minimum version again. Hopefully the "Waterfox Current" release stabilizes soon. It looks like they have an alpha release based on Firefox v68.

[Gudahtt]

I've just reviewed the metrics for this month so far, and it turns out that _very few_ users are using Chromium 58.x or 59.x. Of the identifiable browsers present in our metrics, only a single visit is from a user within that range.

Given that, it should be fine for us to increase the minimum supported Chrome version to 60, so that we no longer need to transpile Object rest/spread.

[whymarrh]

Yeah I would suggest we bump our minimum Chromium version to at least support rest parameters and the spread syntax.

[Gudahtt]

Motivated by a new incompatibility we've discovered in a dependency (see #10014), I've taken another look at our metrics to see how many users are using browsers based on Chromium v62 or lower, and the answer is "not many". Of the browser forks I was able to identify an equivalent Chromium fork for (using map-to-chrome), a total of one user was on a browser based on a Chromium version below v63 (Yandex 16.6.1.7469 specifically). There is a surprising amount of usage of Chromium v63-based browsers, but practically nothing below that. This is from looking at the last 1 month of metrics.

Based on that, I think we can safely increase the minimum Chrome version to 63.