The version field is now stored in the main `package.json` file rather
than in the base manifest. It is built into the final manifest during
the build script.
This makes it easier to communicate what the current version should be
to our `auto-changelog` script. It's also generally a more conventional
place to keep track of the version, even considering that we're not
publishing to npm.
The Firefox e2e tests now use the `.zip` file for testing the
extension. We've found this to produce more similar results to
production, compared to the old method of loading the unzipped
directory.
Passing in a `.zip` file to the Chrome driver didn't seem to work. I
didn't investigate this further to see if it was possible, but I'm not
sure it makes a difference on Chrome anyway.
The e2e test driver used to perform the initial navigation
automatically within the `buildWebDriver` function, so that that step
wouldn't need to be repeated at the beginning of each test. However
this prevented you from doing any setup in the test before the first
navigation.
The navigation has now been moved into each individual test. It should
be functionally equivalent, except now it's possible to control exactly
when the first navigation occurs.
A 1 second delay was also removed, as it didn't seem to be necessary
when testing this. It was initially added as an attempted fix to an
intermittent failure. It did not fix that failure.
* Remove use of ethgassthat; use metaswap /gasPrices api for gas price estimates
* Remove references to ethgasstation
* Pass base to BigNumber constructor in fetchExternalBasicGasEstimates
* Update ui/app/hooks/useTokenTracker.js
Co-authored-by: Erik Marks <25517051+rekmarks@users.noreply.github.com>
* Delete gas price chart
* Remove price chart css import
* Delete additional fee chart code
* Lint fix
* Delete more code no longer used after ethgasstation removal
Co-authored-by: Erik Marks <25517051+rekmarks@users.noreply.github.com>
A few inconsistencies in JSDoc formatting have been fixed throughout
the project. Many issues remain; these were just the few things that
were easy to fix with a regular expression.
The changes include:
* Using lower-case for primitive types, but capitalizing non-primitive
types
* Separating the parameter identifier and the description with a dash
* Omitting a dash between the return type and the return description
* Ensuring the parameter type is first and the identifier is second (in
a few places it was backwards)
* Using square brackets to denote when a parameter is optional, rather
than putting "(optional)" in the parameter description
* Including a type and identifier with every parameter
* Fixing inconsistent spacing, except where it's used for alignment
* Remove incorrectly formatted `@deprecated` tags that reference non-
existent properties
* Remove lone comment block without accompanying function
Additionally, one parameter was renamed for clarity.
* Fix require-unicode-regexp issues
See [`require-unicode-regexp`](https://eslint.org/docs/rules/require-unicode-regexp) for more information.
This change enables `require-unicode-regexp` and fixes the issues raised by the rule.
* Remove case-insensitive flag from regexps
The webdriver method `verboseReportOnFailure` had previously taken a
single parameter, `test`, which was an object representing the current
Mocha test. However, only one property was used (`title`).
Instead the `title` is now passed through directly. This was done to
make this function easier to use outside of a Mocha context.
The `AccountDetailsDropdown` component has been rewritten to use the
new `Menu` component, and to follow the latest designs.
This should be functionally equivalent. A couple of the icons have
changed, but that's about it.
Support for a subtitle was added to `MenuItem` to support the `origin`
subtitle used for the explorer link for custom RPC endpoints.
A few adjustments were required to `test/helper.js` to accommodate
the use of `Menu` from a JSDOM context (this is the first time it's
been used in a unit test). A `popover-content` element was added to the
fake DOM, and another global was added that `react-popper` used
internally.
An additional driver method (`clickPoint`) was added to the e2e driver
to allow clicking the background behind the menu to dismiss it. This
wasn't possible using the `clickElement` method, because that method
would refuse to click an obscured element. The only non-obscured
element to click was the menu backdrop, and that didn't work either
because the center was obscured by the menu (Selenium clicks the center
of whichever element is targeted).
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 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`.
There have been intermittent test failures at the beginning of various
e2e test runs. Most tests start with waiting for the 'Welcome' button
to be visible and enabled, which means waiting for the loading screen
to go away.
It looks like the reason the test intermittently fails is that
sometimes the loading screen doesn't appear until a few moments _after_
the page loads (or that it vanishes and comes back).
It was rather difficult to track down each possible cause for the
loading screens, so in the meantime a pause has been added at the start
of each run. This should hopefully suffice to ensure the momentary gap
in loading has been passed by the time the first test starts up.
The driver now has a page navigation function that can navigate to any
of the three primary pages used in the extension. Additional pages and
support of paths can be added later as needed.
The switch case has been moved to a separate function so that the
initialization steps following the web driver instantiation could more
easily be deduplicated.
* Wait until element is clickable before clicking in e2e tests
A new `findClickableElement` has been added to the webdriver to allow
finding an element and blocking until it's both visible and enabled.
This is now used by the pre-existing `clickElement` method as well.
All cases where something is clicked in the e2e tests have been
updated to use one of these methods, to ensure we don't run into
intermittent failures when loading screens take longer than usual.
* Specify type before parameter name
Various JSDoc `@param` entries were specified as `name {type}` rather
than `{type} name`.
A couple of `@return` entries have been given types as well.
* Use JSDoc optional syntax rather than Closure syntax
* Use @returns rather than @return
* Use consistent built-in type capitalization
Primitive types are lower-case, and Object is upper-case.
* Separate param/return description with a dash
The Selenium webdriver is difficult to use, and easy to misuse. To help
use the driver and make it easier to maintain our e2e tests, all driver
interactions are now performed via a `driver` module. This is basically
a wrapper class around the `selenium-webdriver` that exposes only the
methods we want to use directly, along with all of our helper methods.
Update `selenium-webdriver` to v4.0.0-alpha.5. Despite the fact that
this version has "alpha" in the name, the maintainer of
`selenium-webdriver` has described this release as stable [1].
A few APIs were removed or changed in v4, which required changes to our
Firefox webdriver.
The port used for webdriver communication can now be specified
manually. This was required to ensure the threebox tests kept working,
because they used two different driver instances. This new version of
`selenium-webdriver` now uses the same port for each instance of the
webdriver (unlike the old version, which generated a new port for each
one), so it was necessary to manually specify the port to prevent the
same port from being used for both instances.
`chromedriver` required an update, as the version we were using was not
compatible with the new W3C WebDriver protocol. I've updated
`geckodriver` as well, just to bring it in line with the version of
Firefox we are using.
[1]: https://github.com/SeleniumHQ/selenium/issues/5617#issuecomment-373446249
