This tests the `personal_sign` method using the test dapp. This test
reflects part of the `confirm-sig-requests` integration test, which
tests the confirmation of a `personal_sign` signature request.
A `data-testid` prop was added to the 'Sign' button on the signature
request confirmation page, to make it easier to select the 'Sign'
button reliably.
Both the primary and secondary balance components on `EthOverview` now
have `data-testid` props, so that they can be more easily referenced in
e2e tests.
This required the addition of a `data-testid` prop to the component
`UserPreferencedCurrencyDisplay`, which is passed through to the
underlying `CurrencyDisplay` component.
When a suggested token was resolved in a different window, the popup
or notification UI could get stuck with an empty suggested token list,
where either action would throw an error.
This case is now handled by either redirecting or closing the window,
in the popup and notification cases respectively. This check is
performed on both component mount and update.
The "confirm suggested token" page allowed the confirm button to be
pressed even when there were no tokens to confirm. This can happen
sometimes when the page is in the process of redirecting.
The inline speedup and speedup cancellation buttons in the activity log
were broken. An exception would be thrown upon either button being
clicked, and nothing would happen from the user's perspective.
Both handlers were being passed a transaction id, which was a holdover
from before the transaction list redesign. The handlers passed for
these two actions now have the transaction id embedded, so it doesn't
need to be passed in anymore. They expect the click event to be passed
through instead.
The handlers passed also didn't handle closing the transaction details
modal when clicked. After fixing the first problem, they still didn't
work because the speedup/cancel dialog was shown behind the transaction
details modal.
Both issues are now fixed. Both buttons now close the transaction
details modal, and trigger the appropriate action.
Previously the `getMessage` function would throw if a substitution was
falsey. Now it will accept any substitution, including `undefined`.
A substitution of `null` or `undefined` will still be reported to
Sentry and printed to the console as an error, but it will not
interrupt execution. Any `null` or `undefined` substitutions will be
rendered as empty strings.
Ideally we'd never pass in `null` or `undefined` as a substitution, but
in practice this sometimes just occurs breifly between renders, which
isn't a severe enough problem to justify crashing the UI.
The detection of React component substitutions has been updated as
well, to ensure that `null` values aren't counted as React
substitutions.
The CSS `opacity` rule accepts percentages on newer browsers, but some
older browser versions we support (e.g. Firefox v60) doesn't support
them. A number is now used instead, which is supported by all browsers
we support.
We were including the polyfill for the `Intl.RelativeTimeFormat` API,
but we weren't including any locale data. This polyfill doesn't work
without the locale data for whichever locale you're formatting.
The data for all locales we support is now included. The locale data
is loaded from disk as-needed (during app startup, and upon each change
in locale).
The `getMessage` function in `i18n-helper` was assuming that any
substitutions passed into the transaction function were used by the
corresponding localized message. However, some messages are
intentionally ignoring substitutions passed in. This was done to
simplify the UI logic, so the same substitutions could be passed in for
many different messages, even if some don't use them.
For example, `transactionCancelSuccess` is passed two substitutions but
only uses the second one. `transactionErrored` is passed in two, but
uses neither.
`getMessage` has been updated to no longer make that assumption. It
will now only throw an error if the localized message expects a
substitution that was not given. A given substitution that is unused
results in no error.
There was a case where the `activeTab.origin` was not set, yet the user
could still navigate to the "Connected accounts" modal, which assumes
that `activeTab.origin` is set. This would happen in Firefox when the
user opened the popup on a page internal to Firefox (e.g.
`about:blank`). The connected status indicator would still be shown,
but the UI would crash when it was clicked.
The connected status indicator is now hidden whenever
`activeTab.origin` is falsy. The 'Unconnected account' alert has also
been made impossible to trigger in that circumstance.
The designs for the connect flow show the site `origin` below the site
icon rather than the site name. This was done for security reasons,
and because the site name is often set to an unwieldy long string.
This was accidentally undone in #8815 in the process of fixing a
separate bug. The origin has now been restored. More specific PropTypes
have been set on each use of the `domainMetadata` prop as well.
The account list on the unconnected account alert was in the wrong
order; they were in the order provided by the permissions controller
rather than by last active.
The accounts are now sorted correctly; first by last active, second by
the keyring controller order.
The `getPermittedIdentitiesForCurrentTab` selector was removed because
it is no longer used.
The mobile sync redirect was failing due to a typo in a prop. It would
fail to redirect correctly in the event of a timeout, or after pressing
'Cancel'.
The 'copy-to-clipboard' icon was removed in #8190, and replaced with a
new 'Copy' icon component. It was still being used in two places
though, on the confirmation page for decryption and on the reveal seed
phrase screen..
The new Copy icon is now used in these two places instead. It has been
given a size of '17' to match the old icon size.
We were showing exported private keys in all upper case. This is
atypical, and many other wallets (e.g. MyCrypto) expect private keys
for imported accounts to be lower-cased. Our own account import is
tolerant of either case.
in both permission flows the checkboxes were using the fa-check icon, and in the case
of the connected accounts popover the color of the icon was wrong. It occurred to me
while simply fixing that color would have been easier, we will be adding permissions
at some point in the future that a user will be able to 'uncheck'. This PR replaces
the usages of those icons with the Checkbox component that is equipped to handle the
interactivity of checking/unchecking.
Fixes#8835
In cases where the registry failed to load, and the sig is set to `{}` on this line: e85b162651/ui/app/helpers/utils/transactions.util.js (L78) this proceeds to set the method prefix to `{}` in knownMethodData.
Additionally check if the method prefix object is empty to proceed call getMethodDataAsync again.
I could only reproduce by intentionally failing the method registry lookup and found this solution. I could not find an instance where the registry consistently failed to lookup even on slow/throttled/high latency networks.
The connected status indicator had been moved left since this popup was
first written. The position of the highlighted portion of the
background has been updated reflect this.
* fix overflowing contract names and origins
Moves heading and subtitle into divs with h3/h2 children so that the
div can be display flex and still have ellipses overflow. Only the
heading was display flex but I wanted the two to have similar structure.
this allows subheading to be display flex in the future.
Also uses stripHttpSchemes to remove that from origin in the subheading
* rtl ellipses on domain
* Update ui/app/components/app/transaction-list-item/index.scss
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
The 'Expand view' button in the 'Account Options' menu was still being
shown on the fullscreen UI. This button is not useful in fullscreen, as
all it does is open the fullscreen UI. It is now hidden on the
fullscreen UI.
The letter chosen for the fallback site icon was being set
inconsistently throughout the extension. The connect flow was using the
first letter of the `origin` for the letter (which was always `H`,
because `HTTP`), but the connect sites list and the account menu were
using the `name` from the domain metadata.
The `name` is now used for the fallback icon everywhere. A selector
that supplied a default domain metadata object has also been augmented
to use the `hostname` rather than the `origin` as a fallback name, to
match the behavior of the inpage provider.
A new `SiteIcon` component has been created for showing icons
representing web3 sites. The icon has a border and background, and it
has a fallback in case no icon is given. This new component accepts a
`size` prop that controls the size of the icon.
The old `IconWithFallback` component had a hard-coded size in the
SCSS styles for the icon, which was being overridden in a few places.
It was difficult to customize, and overly complicated.
The old `IconWithFallback` component is still used, but it's now
simpler. It only handles rendering the underlying `img` for the icon,
or the fallback letter if no image is given.
A separate `IconBorder` component has been created for the border and
white background used. It's solely used by `SiteIcon` for now, but I
intend to use it elsewhere as well, where this same pattern of a white
background is embedded.
* update connected accounts appearance
* consolidate account alerts
* UnconnectedAccountAlert: use ConnectedAccountsList
* move switch account action out of menu in all views
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
Imported accounts can be removed, but the permissions controller is not
informed when this happens. Permissions are now removed as part of the
account removal process.
Additionally, the `getPermittedIdentitiesForCurrentTab` selector now
filters out any non-existent accounts, in case a render occurs in the
middle of an account removal.
This was resulting in a render crash upon opening the popup on a site
that was connected to the removed account.
Token transfers will now be hidden on the ETH asset page. Arguably
token transfers are still relevant to show on the ETH asset page
because the gas for token transfers is paid in ETH, but they weren't
being displayed in a way that highlighted this (only the token amount
was shown inline - not the gas price).
We will likely restore token transfers to the ETH asset page at a later
date, after designs have been updated to highlight their relevance to
this page.
