These tests broke when `sinon.restore()` was called in a separate test
because they setup stubs/spies using `sinon` in the module context.
These were constructed then restored before the tests even ran.
Instead the test doubles are now setup in the `beforeEach` hook, which
in addition to fixing this problem also ensures each unit test is
isolated from the others.
* Refactor tab styles to minimize tab component styles
The tab component styles were not applicable to all tab instances, so
they were being overridden in a few places. Instead the tab styles have
been reduced to a minimal set that should be applicable in most cases.
There are a few functional changes here as well, meant to undo
changes made accidentally in #8132. Before that PR the page container
was overriding the tab styles altogether, but after that PR they were
combined with the base tab styles instead.
* Remove background color
This was previously being overridden by the page container styles, and
it matches the inherited background color already in the one other case
(the confirm page for token interactions)
When the token tracker is first constructed and the first balance
update is triggered, we manually serialize the tracker state and call
our update function. This is _in addition_ to the update event handler
though, so the balances get updated twice. Similarly, we also catch any
errors during this first update to handle them, but this is done via an
event as well, so is redundant.
These steps have been removed; updates and errors are now handled
solely through events. We were able to drop a check from
`updateBalances` as well to ensure the tracker is still running, as the
event cannot be emitted unless it's running.
* Add minimal working popover
* Fix styling of popover component
* Use lorem ipsum
* Update classnames and remove unrelated styles
* Remove unused components
* Add SVG close icon
* Add Close icon to icon stories
* Use div
* Use `addon-actions`
* Use `<button>` for close
* Fix button wobble in Firefox
* Remove border
* Add tx list-item component
New list item compoent for transaction history
* Simplify component logic and remove type checks
* Address remaining feedback
* Remove extra line
* Place className prop on its own line
* Rename to primaryCurrency and secondaryCurrency
* Make the title `isRequired`
* Fix no-undef
* Remove more + buttons to be implemented in seperate PR
* Add minimal store and I18nProvider to storybook
* Use Component to support translations
* Add `metamask` to store
* Rename decorator
The current selected asset in the asset list should be highlighted, but
this highlighting was broken for `ETH`. `ETH` was not highlighted when
it was selected, but it would be highlighted when anything else was.
This was broken accidentally in #7546
The props `isActive` and `tabIndex of the Tab component are required
and are always passed in, but the prop type warning is triggered
because the tabs are rendered without these props first, then cloned by
the `Tabs` component, where these props are added.
To silence the warning, the props have been made optional.
The sidebar used to speed up a transaction while it's pending or after
it has failed currently allows editing the gas limit, but that new
limit is ignored. This is especially problematic for transactions that
failed due to a low gas limit, as the problem becomes impossible to fix
by retrying.
The gas limit specified by the user is now used in the speed up
transaction.
Fixes#8156Fixes#7977
The `createRetryTransaction` was accidentally removed from the
`gas-modal-page-container` component during a refactor in #7730.
Attempting to retry a transaction since that change has resulted in a
UI crash.
* Adds notification icon circles and associated storybook stories
* Fix image paths in circle-icon.stories and message-circle-icon.component
* Code improvements for icon circles PR: remove additional z-index, make iconSource required
* Use component story format in circle-icon.stories and message-circle-icon.stories
* Remove success and info circle icons, as not presently needed
* Rename message-circle-icon to alert-circle-icon
* Small code fix ups for alert-circle-icons
The base component we use for dropdowns handles ensuring the dropdown
is closed when the user clicks outside the dropdown. This functionality
was accidentally broken in #7781 when converting it to an ES6 class.
The "Transaction View" component has been merged with the Home
component. The division between these two components seemed wrong
because the "Transaction View" contained the menu bar (distinctly a
"home" thing, not a "transaction" thing), and we will be adding more
non-transaction-related components shortly.
This also let us use a single `Media` component instead of two.
The notifications displayed on the home screen were being passed
through the `TransactionView` and `TransactionList` components before
being rendered. This was unnecessary because the notifications are
absolutely positioned.
They are now rendered directly in the home component where they're
defined. A helper function has been written to improve readability.
This effectively covers the `Tab` component as well, which doesn't
really make sense to showcase on its own.
One minor change was made to the actual `Tabs` component; `children`
was marked as a required prop. It doesn't render anything sensible if
they are omitted, and it always has at least one child in our codebase.
The tab component now sets the `tab` and `tab--active` classes
internally regardless what class is passed in. The convention in React
is to allow adding _additional_ classes via the `className` prop, not
to allow removing internal classes entirely.
the `activeClassName` prop was removed entirely. A few other props that
are always passed in have been marked as required.
One main configurable story has been added, plus a few distinct other
examples. All props are covered except `className`, which seems safe to
ignore.
Default props have been added to `Identicon` to make more explicit what
defaults were expected; there is no functional change.
The recommended way of writing stories changed in Storybook v5.2 to
the Component Story Format (CSF). Instead of using `storiesOf` and
running everything upon module import, the new story format is a
declarative description of each component that uses ES6 import
semantics.
Previously when the `diameter` prop of the `jazzicon` component was
changed, the new diameter would be ignored. The jazzicon is now
redrawn upon each change, as you would expect.
I don't think it's possible for this bug to manifest itself in the
extension. This was discovered through tinkering with the Storybook
for this component.
The identicon was showing as a white circle on the connect page. This
was a CSS error introduced when `jazzicon` was updated in #7898.
The white circle shown was the white border around the identicon. This
circle is an adjacent `div` in the DOM, and was rendered _underneath_
the identicon itself because it was placed first in the DOM.
Unfortunately the new version of `jazzicon` is no longer explicitly
positioned (it used to have `position: relative` set internally), so
now it's lower in the stack order regardless of DOM position.
Rather than placing the border adjacent and relying upon both elements
being positioned, the border has been changed into a wrapping `div`
instead. Now the stack order is more explicit.
The QR scanner component error handling would sometimes redirect the
user to the wrong page. It was also confusingly handled in two places;
the action used to open the QR scanner, and the scanner component.
The error handling has now been corrected, simplified, and integrated
into the QR scanner component itself.
The old way of handling an error within the component was to close the
modal, then call the action to open it all over again. This action took
a route parameter, which instructed the action on which route to open
if the fullscreen UI needed to be opened (as the fullscreen UI is the
only one where the browser will show the camera permission prompt).
This redirection worked just fine for handling the initial opening
of the QR scanner modal. But for any subsequent errors the same action
was used with a _default route_, meaning the user could click "try
again" and find themselves on a completely different screen.
Instead, errors now trigger a state change instead of closing and re-
opening the modal. The permission checks in the action have been
integrated into the component as well.
One functional change is that the scenario where you have an invalid
QR code has been made an error. Previously this just showed the error
message below the video preview, but left the user with no way to try
again. There error page has a "Try again" button, so it seemed better
suited as an error. Also the message literally started with "Error:".
Another functional change is that _all_ errors during initialization
will result in the error UI being shown. Previously there was one error
case that would instead log to the console and leave the user stuck.
* 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
* Various component tests and some conditional statements
Conditional in account-menu in removeAccount when keyring sometimes is not initially provideed
Conditional on unlock-page when there is no target.getBoundingClientRect on the element.
* Update helpers
* Remove component debugging
* Add default params for render helpers
* Remove stubComponent for old Mascot
Changes in https://github.com/MetaMask/metamask-extension/pull/7893 has prevented the need to stub it out.
Change logout to lock in account-menu test
The custom spend limit was previously not validated. It did have a
minimum of zero set, but this didn't have any affect (that minimum is
used for form constraint validation, and this field wasn't in a form).
The field was never checked to ensure the contents didn't exceed the
maximum.
The field is now checked for values that exceed the maximum, and
invalid values in general (including negative values).
The parameters to the `showEditApprovalPermissionModal` were also
alphabetized to make them easier to read. In the course of doing this,
I noticed that the origin was missing from one of the calls. This was
responsible for the modal saying "Spend limit requested by undefined"
when clicking "Edit" under the transaction details. This has been
fixed.
The custom spend limit was previously not validated. It did have a
minimum of zero set, but this didn't have any affect (that minimum is
used for form constraint validation, and this field wasn't in a form).
The field was never checked to ensure the contents didn't exceed the
maximum.
The field is now checked for values that exceed the maximum, and
invalid values in general (including negative values).
The parameters to the `showEditApprovalPermissionModal` were also
alphabetized to make them easier to read. In the course of doing this,
I noticed that the origin was missing from one of the calls. This was
responsible for the modal saying "Spend limit requested by undefined"
when clicking "Edit" under the transaction details. This has been
fixed.
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.
In the case where the initial spend limit for the `approve` function
was set to the maximum amount, editing this value would result in the
new limit being silently ignored. The transaction would be submitted
with the original max spend limit.
This occurred because function to generate the new custom data would
look for the expected spend limit in the existing data, then bail if
it was not found (and in these cases, it was never found).
The reason the value was not found is that it was erroneously being
converted to a `Number`. A JavaScript `Number` is not precise enough to
represent larger spend limits, so it would give the wrong hex value
(after rounding had taken place in the conversion to a floating-point
number).
The data string is now updated without relying upon the original token
value; the new value is inserted after the `spender` argument instead,
as the remainder of the `data` string is guaranteed to be the original
limit. Additionally, the conversion to a `Number` is now omitted so
that the custom spend limit is encoded correctly.
Fixes#7915
Mark Stacey
ricky
Brad Decker
MetaMask Bot
Thomas Huang
Dan J Miller
Erik Marks
Whymarrh Whitby
Vodopyanov Egor
ryanml