1
0
mirror of https://github.com/kremalicious/metamask-extension.git synced 2024-10-24 20:32:02 +02:00
Commit Graph

11 Commits

Author SHA1 Message Date
Erik Marks
76a2a9bb8b
@metamask/eslint config@5.0.0 (#10358)
* @metamask/eslint-config@5.0.0
* Update eslintrc and prettierrc
* yarn lint:fix
2021-02-04 10:15:23 -08:00
Thomas Huang
425ec6228c
Use nativeCurrency in the confirm approve screen (#10298)
Gets nativeCurrency from state and uses in place of the previously hardcoded ETH value in the confirm approve component.
2021-01-27 22:44:04 -08:00
David Walsh
a05230bba7 Provide alternative text for images where appropriate 2020-11-11 09:38:15 -06:00
Brad Decker
2ebf8756a4
[RFC] add prettier to eslint (#8595) 2020-11-02 17:41:28 -06:00
Whymarrh Whitby
6b6615be27
Enable react/jsx-first-prop-new-line for multiline, single prop JSX (#8276)
* Enable react/jsx-first-prop-new-line for multiline, single prop JSX
* yarn lint --fix
2020-04-01 18:08:19 -02:30
Mark Stacey
59a1746afc
Validate custom spend limit (#7920)
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.
2020-01-29 14:16:38 -04:00
Mark Stacey
cc78378b8e
Allow editing max spend limit (#7919)
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
2020-01-28 22:49:32 -04:00
Mark Stacey
49a525b9f8
Add react/no-unused-prop-types ESLint rule (#7655)
* Add `react/no-unused-prop-types` rule

All detected unused prop types have been removed. I have attempted to
ensure these props are no longer passed in either.

* Update handling of props to avoid false positive lint errors

These cases were detected by `react/no-unused-prop-types` as being
unused props, even though they were used. These minor adjustments
prevent them from being flagged as errors.

* Update unit tests

Many of these tests were just checking that specific props were passed
from containers or to a child component. These were deleted, as I can't
imagine how they'd be useful.

* Disable `react/no-unused-prop-types` in `componentWillReceiveProps

The rule `react/no-unused-prop-types` doesn't seem to be detecting
props used within `UNSAFE_componentWillReceiveProps`. The two cases
have been disabled temporarily until we can replace these unsafe
lifecycle functions.
2019-12-07 23:10:47 -04:00
Whymarrh Whitby
2e69f3233e
eslint: Enable more react/jsx-* rules (#7592) 2019-12-03 13:05:44 -03:30
Mark Stacey
5c356a4cac
Show transaction fee units on approve screen (#7468)
The units for the amounts shown on the approve screen in the
transaction fee section were missing. It appears that they were present
in an early version of the approve screen (#7271) but they got lost
somewhere along the way.
2019-11-19 09:41:28 -04:00
Dan J Miller
2673eef3c4
Redesign approve screen (#7271)
* Redesign approve screen

* Add translations to approve screen components

* Show account in header of approve screen

* Use state prop bool for unlimited vs custom check in edit-approval-permission

* Set option to custom on input change in edit-approval-permission

* Allow setting of approval amount to unlimited in edit-approval-permission

* Fix height of confirm-approval popup

* Ensure decimals prop passted to confirm-approve.component is correct type

* Ensure first param passed to calcTokenValue in confirm-approve.util is the correct type

* Fix e2e test of permission editing

* Remove unused code from edit-approval-permission.container
2019-11-05 11:43:48 -03:30