An alert is now shown when the user switches from an account that is
connected to the active tab to an account that is not connected. The
alert prompts the user to dismiss the alert or connect the account
they're switching to.
The "loading" state is handled by disabling the buttons, and the error
state is handled by displaying a generic error message and disabling
the connect button.
The new reducer for this alert has been created with `createSlice` from
the Redux Toolkit. This utility is recommended by the Redux team, and
represents a new style of writing reducers that I hope we will use more
in the future (or at least something similar). `createSlice` constructs
a reducer, actions, and action creators automatically. The reducer is
constructed using their `createReducer` helper, which uses Immer to
allow directly mutating the state in the reducer but exposing these
changes as immutable.
`pify` v5.0.0 will preserve `this` references correctly, so explicit
binding of objects passed to `pify` is no longer needed.
There are no breaking changes that affect us; the only breaking change
in v4 and v5 is to update the minimum Node.js version to v10.
Previously all browser globals were allowed to be used anywhere by
ESLint because we had set the `env` property to `browser` in the ESLint
config. This has made it easy to accidentally use browser globals
(e.g. #8338), so it has been removed. Instead we now have a short list
of allowed globals.
All browser globals are now accessed as properties on `window`.
Unfortunately this change resulted in a few different confusing unit
test errors, as some of our unit tests setup assumed that a particular
global would be used via `window` or `global`. In particular,
`window.fetch` didn't work correctly because it wasn't patched by the
AbortController polyfill (only `global.fetch` was being patched).
The `jsdom-global` package we were using complicated matters by setting
all of the JSDOM `window` properties directly on `global`, overwriting
the `AbortController` for example.
The `helpers.js` test setup module has been simplified somewhat by
removing `jsdom-global` and constructing the JSDOM instance manually.
The JSDOM window is set on `window`, and a few properties are set on
`global` as well as needed by various dependencies. `node-fetch` and
the AbortController polyfill/patch now work as expected as well,
though `fetch` is only available on `window` now.
The Font Awesome font wasn't loaded correctly in the Storybook build.
Unlike our other fonts, Font Awesome is copied from `node_modules` at
build-time rather than being saved directly in `app/fonts`.
The `copy-webpack-plugin` plugin is now used in the Storybook webpack
build to copy the fonts explicitly from `node_modules` into the build
output directory. The font now seems to load correctly in Storybook.
The official npm package for Font Awesome Free is now used instead of
the vendored styles. Previously we had been using v4.4.0, now we're
using v5.13.0.
We're now importing the Font Awesome SCSS modules instead of using the
minified CSS bundle. This integrates more cleanly into our build
system, and it lets us use their mixins directly in the future if we
need to.
The variable `fa-font-path` has been set to reference our font
directory, as instructed here:
https://fontawesome.com/how-to-use/on-the-web/using-with/sass#compile
Various SVGs were being imported directly in components using Webpack
loaders. This was done to get these components to work correctly in
storybook, which uses Webpack. However we don't use Webpack for our
actual build system, so these components would fail when you attempted
to use them.
Instead the storybook script has been updated to use the `--static-dir`
flag, which allows specifying a directory of files to serve statically.
The `app` directory is served statically, so all of the relative URLs
we use in practice to reference fonts and images should just work.
The storybook build command has been updated to use the same flag.
Unfortunately this also means that the uncompiled background code is
now included in the build as well, because it's alongside our static
files. This shouldn't have any impact upon the build though.
The use of this `static-dir` option as made much of the existing
storybook Webpack configuration unnecessary, so it has been reduced to
just the essential steps.
The token list would be stuck on "Loading" when there was at least one
token, but the balance of all tokens was zero. This bug was only
present on `develop`, and has not affected any published version of the
extension.
This was introduced in #8223, which removed what at the time seemed to
be an unnecessary update step. It turns out that the step was required
as a workaround to this bug with the token tracker.
The bug was fixed in https://github.com/MetaMask/eth-token-tracker/pull/33
and published in v2.0.0 of `@metamask/eth-token-tracker`.
The `@storybook/addon-backgrounds' addon has been added, which allows
changing the component preview background. By default no background
colors are defined, though there is a helpful grid button. A "light"
and "dark" background option has been added globally. Additional
story-specific backgrounds or global backgrounds can be added later if
necessary.
This warning was resolved by updating `pubnub`, which is the dependency
that uses `superagent-proxy` which is causing this warning. The
resolution we added to address a security advisory is also no longer
required.
This was primarily done to make explicit that we're using v5.3.x. Our
manifest listed `^5.2.x` but we had already updated to `v5.3.9` in the
lockfile. v5.3.0 lays much of the groundwork for the planned v6.0
release, and includes many changes.
The changes between v5.3.9 and v5.3.14 include various bug fixes, none
of which affect us as far as I know.
Peer dependencies required by Storybook have also been added. These
were already in our dependencies indirectly either way.
Implement `eth_decrypt` and `eth_getEncryptionPublicKey`. This allows decryption backed by the user's private key. The message decryption uses a confirmation flow similar to the messaging signing flow, where the message to be decrypted is also able to be decrypted inline for the user to read directly before confirming.
* Use @metamask/eslint-config@1.1.0
* Use eslint-plugin-mocha@6.2.2
* Mark root ESLint config as root
* Update Mocha ESLint rules with shared ESLint config
These two functions differ slightly in options, but none of those
options are being used by us, so in these cases they're functionally
equivalent. They're even both descendants of the original `debounce`
function from `underscore`.
This was done to reduce the number of direct dependencies we have. It
should not affect bundle size, as we still depend upon the `debounce`
package transitively.
This was done to reduce the number of direct dependencies we have. It
should be functionally equivalent. The bundle size should not change,
as we use `clone` as a transitive dependency in a number of places.
* Use ref instead of findDOMNode in jazzicon component
The jazzicon component was using `findDOMNode` to get the DOM node for
the main div returned by the component, which is generally not
recommended. Instead a ref is now used.
* Update Jazzicon to v2
This version drops the dependency upon `raphael`, and no longer uses
the function `createSVGMatrix` which was causing unit tests to fail
(because it's not supported by jsdom).
Our JSDoc documentation has not been updated in a very long time, and
we don't use JSDoc in enough places for the docs to have been
especially useful. The tools and scripts used to generate and publish
these docs have been removed.
References to this documentation have also been removed from the
README.
Hopefully once the TypeScript migration has made substantial progress,
we can generate more useful documentation using something like TypeDoc.
Update accounts permission history on accountsChanged
Create PermissionsLogController
Fix permissions activity log pruning
Add selectors, background hooks for better UX
Make selected account the first account returned
Use enums for store keys in log controller
Add last selected address history to PreferencesController
* Update lodash
All versions of the full `lodash` package have been updated to 4.17.15.
The only exception is v4.17.14 which is pinned by `ganache-core`.
* Switch to using `lodash` instead of per-method packages
We have the full lodash package _ten times_ as a production transitive
dependency, so including per-method packages is not saving space (it
might instead result in slightly more space being used).
Unhandled rejections are now caught using built-in Node.js APIs instead
of with `bluebird`. `bluebird` was added as a production dependency but
was only used for this purpose. The code responsible for catching
unhandled rejection in the browser was removed, as this test helper is
never run in the browser.
Additionally, unhandled rejections are tracked over the course of all
tests, and result in a non-zero exit code if they remain at the end.
This was done because it is possible for errors to trigger the
`uncaughtRejection` event but then still be handled later on. This is
uncommon, and doesn't seem to happen in our test suite. But if it does
in the future, it'll be logged but won't result in a non-zero exit
code.
This patch update includes a bug fix for ES6 imports. The bug doesn't
affect our use of this module, but it ensures that we can safely
use the `dedupe` and `bind` APIs as ES6 imports if we decide to.
* Minimum changes to get storybook working
Undo path changes
* Add build:storybook scripts to package.json
* Add storybook deployer
* Add storybook:deploy to package.json
* Update circle ci config
* Update yarn.lock
* Remove addon-info
* Update yarn.lock file to reflect removing of addon-info
Co-authored-by: Dan J Miller <danjm.com@gmail.com>
`node-fetch` is a smaller and simpler project than `request-promise`,
and we already have it as a transitive dependency.
`request-promise` was also incorrectly listed as a production
dependency. `node-fetch` has been added as a `devDependency` to replace
it, as it was only used in one CI script.
The only web API that our usage of DetectRTC relied upon was
'enumerateDevices', which is supported and stable among all of our
supported browsers.
Note that the error handling here is a little... non-standard, and the
logic around how Firefox and Brave are handled should be justified, but
I've left the logic as-is for now to keep this PR small.
The WebRTC spec is fairly stable these days, particularly among the
browsers we support. We don't need this shim for anything. I'm guessing
it may have been added primarily with IE in mind.
A margin of error metric has been added, which is calculated from a 95%
confidence interval. This confidence interval is calculated using
Student's t-distribution, which is generally preferred for smaller
sample sizes (< ~30) of populations following a normal distribution.
The script `benchmark.js` will collect page load metrics from the
extension, and print them to a file or the console. A method for
collecting metrics was added to the web driver to help with this.
This script will calculate the min, max, average, and standard
deviation for four metrics: 'firstPaint', 'domContentLoaded', 'load',
and 'domInteractive'. The variation between samples is sometimes high,
with the results varying between samples if only 3 were taken. However,
all tests I've done locally with 5 samples have produced results within
one standard deviation of each other. The default number of samples has
been set to 10, which should be more than enough to produce consistent
results.
The benchmark can be run with the npm script `benchmark:chrome` or
`benchmark:firefox`, e.g. `yarn benchmark:chrome`.
