Warnings were not shown on the Add Recipient page of the send flow. Now
any send warnings will be shown. This can be tested using an ENS name
with a confusable character in it (the confusable character warning
will be shown).
A condition was also removed that prevented any warnings or errors from
rendering when the user had non-zero contacts or recent addresses. I
have no idea why you'd want to hide warnings or errors if the user had
no contacts or recent addresses. None of these errors even pertain to
contacts or recent addresses.
* Add warning system for 'confusable' ENS names (#9129)
Uses unicode.org's TR39 confusables.txt to display a warning when
'confusable' unicode points are detected.
Currently only the `AddRecipient` component has been updated, but the new
`Confusable` component could be used elsewhere
The new `unicode-confusables` dependency adds close to 100KB to the
bundle size, and around 30KB when gzipped.
Adds 'tag' prop to the tooltop-v2 component
Use $Red-500 for confusable ens warning
Lint Tooltip component
Update copy for confusing ENS domain warning.
* Fix prop type
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
* fixed message text overflow
* reverted and removed mesage title inside message--root
* fixed margin problem in sign message
* removed dead css
* fixed large left padding on data signing
* Use the includeFailedTokens option with useTokenTracker in viewQuote
* Show appropriate error message if we do not have data on the balance of token on the view-quote screen
* Update app/_locales/en/messages.json
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
The `@include Paragraph` was added in one of the typography PRs but I believe it was intended for the token options text, not the icon. I believe the Paragraph only applies to text like everywhere else in the UI and this should be safe to remove from the icon to display the font-family from Font Awesome.
The `transferFrom` localized message has been unused at least since the
transaction list redesign was implemented. The `transactionCategory`
has been used directly as the localized message key since then. For
most of the other categories this was fine, but for `transferFrom` the
message differs slightly from the category (the category is
`transferfrom`, with a lower-cased 'f').
We now use string literals for all transaction category localized
messages. This makes it easier to verify that we have translations for
each of them, and that we aren't leaving any unused translations around.
* Update standard swaps build quote screen token verification message
* Add actionable warning token verification message to swaps build quote screen
* Simplify swapTokenVerification translations
* Use original verifyThisTokenOn message instead of swapsConfirmTokenAddressOnEtherscan
* Restore verifyThisTokenOn message to hi locale
* Support type and the withRightButton option as parameters on the actionable message component
* Use 'continue' in place of swapPriceDifferenceAcknowledgementNoFiat message
* Use wrapperClassName property on infotooltip in actionable-message
* Remove unnecessary change
* Lint fix
* ci - run storybook and add to build-artifacts
* ci/storybook - rename storybook build path and fix artifact upload
* ci/storybook - rename link text
* clean - remove accidently committed storybook build dir
* storybook - fix image path to relative (#10364)
* Use nock in to intercept gas call for gas-duck test
Use nock instead of stubbing out the window fetch. My suspicion is that when the test runs the window sometimes wouldn't be intialized/referenced, which could explain the intermittent test failures in those particular tests that call window.fetch.
Using nock allows the call to be intercepted more reliably.
Upon the first render, the "original" signature request confirmation
page would trigger a PropType error. This was caused by unexpected
mutation of the state props. The container has been updated to avoid
mutating the props, and now the PropType warning is no longer present.
This fixes a bug where the network menu would remain present after a
second click on the network menu button. The bug was caused by the
click being handled _twice_, by two separate handlers. First it was
caught by the external click handler of the dropdown menu, which closed
the menu. Second, it was caught by the network button itself, which re-
opened the menu. This all happens quickly enough that to the user it
appears to stay open.
The external click handler of the menu now only fires if the menu is
open. Additionally, any click that is caught by the network menu is
stopped from propagating further, so that it can't trigger additional
click handlers.
The `menu-droppo` external click handler would fail to update when the
prop changed while the menu wasn't shown. This bug isn't exposed
anywhere yet as far as I know, but I ran into it when working on a
different bug fix.
The Chip component was emitting a PropType error because it was missing
the `labelProps.children` prop. It was never supposed to be given that
prop - it was a mistake in the PropType declaration. The PropTypes have
been fixed to prevent this warning.
Fixes#5611
The origin that suggests a transaction is now shown on the transaction
confirmation page. If the transaction was initiated from within
MetaMask (e.g. via the 'Send' flow or swaps), no origin is shown.
This was based upon designs that were linked in the PR #9377. This is a
temporary measure until our newer transaction confirmation designs can
be implemented.
Fixes#6071
The origin of the dapp that suggested signing has been added to the
signature request confirmation page. This only applies to `eth_sign`,
`personal_sign`, `eth_signTypedData`, and `eth_signTypedData_v1`. The
confirmation page for `eth_signTypedData_v3` and `eth_signTypedData_v4`
already featured the origin.
The decrupt message confirmation UI will crash if the origin metadata
is not present. This PR makes the UI tolerant of that metadata being
missing. It was always intended to be optional anyway.
Fixes#9244
When trying to connect a Trezor account on a fresh install of MetaMask,
the radio buttons on the account selection page would not respond to
being clicked.
When debugging this, it looks like the `onChange` event was never
triggered. A radio `<input>` element should trigger `onChange` whenever
the selection state change, but seemingly this wouldn't happen if the
change in selection state was undone during the same render cycle. If
I paused at a breakpoint during the render, I could see the checkbox
get selected then unselected again without triggering `onChange`.
The simplest fix was to use `onClick` instead of `onChange`. This seems
more appropriate anyway because we're treating the radio button as a
controlled component here, so the state of the underlying element isn't
really of any concern.
The "Next nonce" warning warns users when the custom nonce they set is
higher than our suggested nonce. This warning was mistakenly being
shown even when we didn't have a suggested nonce yet.
Fixes#9989
New year, new problems.
It's working as expected, but we had hard-coded some 2020 date values, and `formatDateWithYearContext` adds the year to its output formatted date if the date is not from the current year.
Ensures that `hideLoadingIndication` is always called in all actions that call `showLoadingIndication`. It's unclear how many of these actions were failing to hide the loading indication, because other actions superset `hideLoadingIndication`.
At the very least, `updateTransaction` was probably failing to hide the loading indication in the error case.
This PR also refactors a lot of actions to call `hideLoadingIndication` once in `finally` blocks as opposed to multiple times across `try` and `catch` blocks. We avoided making changes to functions using `Promise` methods, because `Promise.finally` is not supported by Waterfox, and it's not properly transpiled by Babel.
A data race was introduced in #9919 when the old synchronous storage
API was replaced with an async storage API. The problem arises when
`fetchWithCache` is called a second time while it's still processing
another call. In this case, the `cachedFetch` object can become
stale while blocked waiting for a fetch response, and result in a cache
being overwritten unintentionally.
See this example (options omitted for simplicity, and assuming an empty
initial cache):
```
await Promise.all([
fetchWithCache('https://metamask.io/foo'),
fetchWithCache('https://metamask.io/bar'),
]
```
The order of events could be as follows:
1. Empty cache retrieved for `/foo` route
2. Empty cache retrieved for `/bar` route
3. Call made to `/foo` route
4. Call made to `/bar` route
5. `/foo` response is added to the empty cache object retrieved in
step 1, then is saved in the cache.
6. `/bar` response is added to the empty cache object retrieved in
step 2, then is saved in the cache.
In step 6, the cache object saved would not contain the `/foo`
response set in step 5. As a result, `/foo` would never be cached.
This problem was resolved by embedding the URL being cached directly in
the cache key. This prevents simultaneous responses from overwriting
each others caches.
Technically a data race still exists when handing simultaneous
responses to the same route, but the result would be that the last call
to finish would overwrite the previous. This seems acceptable.
