The method registry was being initialized with the global variable
`ethereumProvider` before that variable was set. As a result, the
method registry was falling back to an internally constructed provider
that used the wrong provider URL (an obsolete Infura API). This was
resulting in an error with the message "Project ID not found".
The method registry is now initialized lazily, when it's first needed.
This should be well after the initialization of `ethereumProvider`,
which occurs during the UI initialization.
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
Errors without stack traces would break the Sentry error processing,
which assumes the presence of a stack trace. Many errors don't have any
stack trace though, such as uncaught promises.
This breakage resulting in the app state being missing from the error
report, and a console warning.
The address is blank momentarily when navigating to the confirmation
screen when sending a token. The address is updated in a subsequent
render.
The ENS reverse resolution is now only attempted if the address is
given. It has also been updated to attempt resolution when the address
is finally set, which fixes the reverse resolution for token sends.
I had hoped to get rid of this interim render-without-address, but that
turned out to be a bit more challenging. The problem is that the UI
submits transactions through the provider just as a dapp would, and the
provider doesn't say when the transaction is submitted. The promise
returned doesn't resolve until after confirmation. We would have to
start calling the background methods directly and bypass the provider
to get the feedback we need, and that sounded potentially dangerous.
Definitely a challenge for another day.
The `metamask.send.from` field was assumed by various selectors to be
an object, but instead it was recently set to a string. The selectors
have been updated to assume it's a string, and to fetch the full
account object explicitly.
The selector `getSendFromObject` was repurposed for this, as that's
basically what it already did. The optional address parameter was
removed though, as that was only used to fetch the `from` address in
cases where the `send` state was set without there being a `from`
address set. That case is no longer possible, as the `from` address is
always set upon the initialization of the `send` state.
The `getSendFromObject` selector no longer fetches the 'name' of that
address from the address book state either. This property was not used
in either of the cases this selector was used.
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
* Update i18n-helper to allow substitutions of react components and wrapping of translation substrings
* Simplify code in i18n-helper.js related to substitutions, including react substitutions.
* Remove wrapper support from i18n in favour of using translations in substitutions.
* Fix i18n-helper substitution logic: ensure correct index of substitution is applied
* Throw error if there are not enough substitutions for a translation phrase
* Adds unit tests for now i18n-helper substitution functionality
* Fix grammar, react element line spacing and test layout+readability in i18n-helper.test.js
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.
The styles used for the Home component were in the huge
"newui-sections" SCSS file. Instead they've been moved into an SCSS
module alongside the component, to follow our conventions.
The `main-container` class was left as-is because it is shared between
here and the settings page.
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 `@storybook/addon-backgrounds' addon has been added, which allows
changing the component preview background. By default no background
colors are defined, though there is a helpful grid button. A "light"
and "dark" background option has been added globally. Additional
story-specific backgrounds or global backgrounds can be added later if
necessary.
This warning was resolved by updating `pubnub`, which is the dependency
that uses `superagent-proxy` which is causing this warning. The
resolution we added to address a security advisory is also no longer
required.
This was primarily done to make explicit that we're using v5.3.x. Our
manifest listed `^5.2.x` but we had already updated to `v5.3.9` in the
lockfile. v5.3.0 lays much of the groundwork for the planned v6.0
release, and includes many changes.
The changes between v5.3.9 and v5.3.14 include various bug fixes, none
of which affect us as far as I know.
Peer dependencies required by Storybook have also been added. These
were already in our dependencies indirectly either way.
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.
Mark Stacey
ricky
Brad Decker
James Prestwich
Erik Marks
Thomas Huang
Dan J Miller
kumavis
Whymarrh Whitby
ryanml