2021-02-04 19:15:23 +01:00
|
|
|
import PropTypes from 'prop-types';
|
2023-02-01 06:54:18 +01:00
|
|
|
import React, { useEffect, useState } from 'react';
|
|
|
|
import { useDispatch, useSelector } from 'react-redux';
|
2023-07-07 10:05:58 +02:00
|
|
|
import { useHistory, withRouter } from 'react-router-dom';
|
2021-02-04 19:15:23 +01:00
|
|
|
import log from 'loglevel';
|
2023-06-01 11:48:07 +02:00
|
|
|
import { cloneDeep } from 'lodash';
|
2023-07-21 11:28:54 +02:00
|
|
|
import { SubjectType } from '@metamask/permission-controller';
|
2021-02-04 19:15:23 +01:00
|
|
|
import * as actions from '../../store/actions';
|
2021-04-28 21:53:59 +02:00
|
|
|
import txHelper from '../../helpers/utils/tx-helper';
|
2021-02-04 19:15:23 +01:00
|
|
|
import SignatureRequest from '../../components/app/signature-request';
|
2022-08-03 16:56:11 +02:00
|
|
|
import SignatureRequestSIWE from '../../components/app/signature-request-siwe';
|
2021-02-04 19:15:23 +01:00
|
|
|
import SignatureRequestOriginal from '../../components/app/signature-request-original';
|
|
|
|
import Loading from '../../components/ui/loading-screen';
|
2023-02-01 06:54:18 +01:00
|
|
|
import { useRouting } from '../../hooks/useRouting';
|
2023-04-25 12:47:12 +02:00
|
|
|
import {
|
|
|
|
getTotalUnapprovedSignatureRequestCount,
|
2023-04-25 16:32:51 +02:00
|
|
|
///: BEGIN:ONLY_INCLUDE_IN(build-mmi)
|
2023-04-25 12:47:12 +02:00
|
|
|
getSelectedAccount,
|
|
|
|
///: END:ONLY_INCLUDE_IN
|
2023-07-21 11:28:54 +02:00
|
|
|
getTargetSubjectMetadata,
|
2023-04-25 12:47:12 +02:00
|
|
|
} from '../../selectors';
|
2021-04-28 21:53:59 +02:00
|
|
|
import { MESSAGE_TYPE } from '../../../shared/constants/app';
|
2023-01-18 15:47:29 +01:00
|
|
|
import { TransactionStatus } from '../../../shared/constants/transaction';
|
2021-06-23 23:35:25 +02:00
|
|
|
import { getSendTo } from '../../ducks/send';
|
2023-05-02 14:36:24 +02:00
|
|
|
import { getProviderConfig } from '../../ducks/metamask/metamask';
|
2016-05-03 23:32:22 +02:00
|
|
|
|
2023-07-21 11:28:54 +02:00
|
|
|
const signatureSelect = (txData, targetSubjectMetadata) => {
|
2023-02-01 06:54:18 +01:00
|
|
|
const {
|
|
|
|
type,
|
|
|
|
msgParams: { version, siwe },
|
|
|
|
} = txData;
|
|
|
|
|
|
|
|
// Temporarily direct only v3 and v4 requests to new code.
|
|
|
|
if (
|
|
|
|
type === MESSAGE_TYPE.ETH_SIGN_TYPED_DATA &&
|
|
|
|
(version === 'V3' || version === 'V4')
|
|
|
|
) {
|
|
|
|
return SignatureRequest;
|
|
|
|
}
|
2020-01-13 18:02:54 +01:00
|
|
|
|
2023-07-21 11:28:54 +02:00
|
|
|
if (siwe?.isSIWEMessage && targetSubjectMetadata !== SubjectType.Snap) {
|
2023-02-01 06:54:18 +01:00
|
|
|
return SignatureRequestSIWE;
|
2018-05-29 19:23:06 +02:00
|
|
|
}
|
|
|
|
|
2023-02-01 06:54:18 +01:00
|
|
|
return SignatureRequestOriginal;
|
|
|
|
};
|
2020-01-13 18:02:54 +01:00
|
|
|
|
2023-02-01 06:54:18 +01:00
|
|
|
const ConfirmTxScreen = ({ match }) => {
|
|
|
|
const dispatch = useDispatch();
|
|
|
|
const { navigateToMostRecentOverviewPage } = useRouting();
|
|
|
|
const unapprovedMessagesTotal = useSelector(
|
|
|
|
getTotalUnapprovedSignatureRequestCount,
|
|
|
|
);
|
|
|
|
const sendTo = useSelector(getSendTo);
|
|
|
|
const {
|
|
|
|
unapprovedTxs,
|
|
|
|
identities,
|
|
|
|
currentNetworkTxList,
|
|
|
|
currentCurrency,
|
|
|
|
unapprovedMsgs,
|
|
|
|
unapprovedPersonalMsgs,
|
|
|
|
unapprovedTypedMessages,
|
NetworkController: Split `network` into `networkId` and `networkStatus` (#17556)
The `network` store of the network controller crams two types of data
into one place. It roughly tracks whether we have enough information to
make requests to the network and whether the network is capable of
receiving requests, but it also stores the ID of the network (as
obtained via `net_version`).
Generally we shouldn't be using the network ID for anything, as it has
been completely replaced by chain ID, which all custom RPC endpoints
have been required to support for over a year now. However, as the
network ID is used in various places within the extension codebase,
removing it entirely would be a non-trivial effort. So, minimally, this
commit splits `network` into two stores: `networkId` and
`networkStatus`. But it also expands the concept of network status.
Previously, the network was in one of two states: "loading" and
"not-loading". But now it can be in one of four states:
- `available`: The network is able to receive and respond to requests.
- `unavailable`: The network is not able to receive and respond to
requests for unknown reasons.
- `blocked`: The network is actively blocking requests based on the
user's geolocation. (This is specific to Infura.)
- `unknown`: We don't know whether the network can receive and respond
to requests, either because we haven't checked or we tried to check
and were unsuccessful.
This commit also changes how the network status is determined —
specifically, how many requests are used to determine that status, when
they occur, and whether they are awaited. Previously, the network
controller would make 2 to 3 requests during the course of running
`lookupNetwork`.
* First, if it was an Infura network, it would make a request for
`eth_blockNumber` to determine whether Infura was blocking requests or
not, then emit an appropriate event. This operation was not awaited.
* Then, regardless of the network, it would fetch the network ID via
`net_version`. This operation was awaited.
* Finally, regardless of the network, it would fetch the latest block
via `eth_getBlockByNumber`, then use the result to determine whether
the network supported EIP-1559. This operation was awaited.
Now:
* One fewer request is made, specifically `eth_blockNumber`, as we don't
need to make an extra request to determine whether Infura is blocking
requests; we can reuse `eth_getBlockByNumber`;
* All requests are awaited, which makes `lookupNetwork` run fully
in-band instead of partially out-of-band; and
* Both requests for `net_version` and `eth_getBlockByNumber` are
performed in parallel to make `lookupNetwork` run slightly faster.
2023-03-31 00:49:12 +02:00
|
|
|
networkId,
|
2023-02-01 06:54:18 +01:00
|
|
|
blockGasLimit,
|
|
|
|
} = useSelector((state) => state.metamask);
|
2023-05-02 14:36:24 +02:00
|
|
|
const { chainId } = useSelector(getProviderConfig);
|
2023-02-01 06:54:18 +01:00
|
|
|
const { txId: index } = useSelector((state) => state.appState);
|
2023-04-25 12:47:12 +02:00
|
|
|
|
2023-04-25 16:32:51 +02:00
|
|
|
///: BEGIN:ONLY_INCLUDE_IN(build-mmi)
|
2023-04-25 12:47:12 +02:00
|
|
|
const selectedAccount = useSelector(getSelectedAccount);
|
|
|
|
///: END:ONLY_INCLUDE_IN
|
|
|
|
|
2023-02-01 06:54:18 +01:00
|
|
|
const [prevValue, setPrevValues] = useState();
|
2023-07-07 10:05:58 +02:00
|
|
|
const history = useHistory();
|
2023-02-01 06:54:18 +01:00
|
|
|
|
|
|
|
useEffect(() => {
|
2020-01-13 18:02:54 +01:00
|
|
|
const unconfTxList = txHelper(
|
2023-02-01 06:54:18 +01:00
|
|
|
unapprovedTxs || {},
|
|
|
|
{},
|
|
|
|
{},
|
|
|
|
{},
|
NetworkController: Split `network` into `networkId` and `networkStatus` (#17556)
The `network` store of the network controller crams two types of data
into one place. It roughly tracks whether we have enough information to
make requests to the network and whether the network is capable of
receiving requests, but it also stores the ID of the network (as
obtained via `net_version`).
Generally we shouldn't be using the network ID for anything, as it has
been completely replaced by chain ID, which all custom RPC endpoints
have been required to support for over a year now. However, as the
network ID is used in various places within the extension codebase,
removing it entirely would be a non-trivial effort. So, minimally, this
commit splits `network` into two stores: `networkId` and
`networkStatus`. But it also expands the concept of network status.
Previously, the network was in one of two states: "loading" and
"not-loading". But now it can be in one of four states:
- `available`: The network is able to receive and respond to requests.
- `unavailable`: The network is not able to receive and respond to
requests for unknown reasons.
- `blocked`: The network is actively blocking requests based on the
user's geolocation. (This is specific to Infura.)
- `unknown`: We don't know whether the network can receive and respond
to requests, either because we haven't checked or we tried to check
and were unsuccessful.
This commit also changes how the network status is determined —
specifically, how many requests are used to determine that status, when
they occur, and whether they are awaited. Previously, the network
controller would make 2 to 3 requests during the course of running
`lookupNetwork`.
* First, if it was an Infura network, it would make a request for
`eth_blockNumber` to determine whether Infura was blocking requests or
not, then emit an appropriate event. This operation was not awaited.
* Then, regardless of the network, it would fetch the network ID via
`net_version`. This operation was awaited.
* Finally, regardless of the network, it would fetch the latest block
via `eth_getBlockByNumber`, then use the result to determine whether
the network supported EIP-1559. This operation was awaited.
Now:
* One fewer request is made, specifically `eth_blockNumber`, as we don't
need to make an extra request to determine whether Infura is blocking
requests; we can reuse `eth_getBlockByNumber`;
* All requests are awaited, which makes `lookupNetwork` run fully
in-band instead of partially out-of-band; and
* Both requests for `net_version` and `eth_getBlockByNumber` are
performed in parallel to make `lookupNetwork` run slightly faster.
2023-03-31 00:49:12 +02:00
|
|
|
networkId,
|
2021-03-01 16:15:42 +01:00
|
|
|
chainId,
|
2021-02-04 19:15:23 +01:00
|
|
|
);
|
2023-02-01 06:54:18 +01:00
|
|
|
if (unconfTxList.length === 0 && !sendTo && unapprovedMessagesTotal === 0) {
|
|
|
|
navigateToMostRecentOverviewPage();
|
2020-01-13 18:02:54 +01:00
|
|
|
}
|
2023-02-01 06:54:18 +01:00
|
|
|
}, []);
|
2019-11-04 13:40:46 +01:00
|
|
|
|
2023-02-01 06:54:18 +01:00
|
|
|
useEffect(() => {
|
|
|
|
if (!prevValue) {
|
|
|
|
setPrevValues({ index, unapprovedTxs });
|
|
|
|
return;
|
2020-01-13 18:02:54 +01:00
|
|
|
}
|
|
|
|
|
2021-02-04 19:15:23 +01:00
|
|
|
let prevTx;
|
2023-02-01 06:54:18 +01:00
|
|
|
const { params: { id: transactionId } = {} } = match;
|
2020-01-13 18:02:54 +01:00
|
|
|
if (transactionId) {
|
2021-02-04 19:15:23 +01:00
|
|
|
prevTx = currentNetworkTxList.find(({ id }) => `${id}` === transactionId);
|
2020-01-13 18:02:54 +01:00
|
|
|
} else {
|
2023-02-01 06:54:18 +01:00
|
|
|
const { index: prevIndex, unapprovedTxs: prevUnapprovedTxs } = prevValue;
|
2021-03-01 16:15:42 +01:00
|
|
|
const prevUnconfTxList = txHelper(
|
|
|
|
prevUnapprovedTxs,
|
|
|
|
{},
|
|
|
|
{},
|
|
|
|
{},
|
NetworkController: Split `network` into `networkId` and `networkStatus` (#17556)
The `network` store of the network controller crams two types of data
into one place. It roughly tracks whether we have enough information to
make requests to the network and whether the network is capable of
receiving requests, but it also stores the ID of the network (as
obtained via `net_version`).
Generally we shouldn't be using the network ID for anything, as it has
been completely replaced by chain ID, which all custom RPC endpoints
have been required to support for over a year now. However, as the
network ID is used in various places within the extension codebase,
removing it entirely would be a non-trivial effort. So, minimally, this
commit splits `network` into two stores: `networkId` and
`networkStatus`. But it also expands the concept of network status.
Previously, the network was in one of two states: "loading" and
"not-loading". But now it can be in one of four states:
- `available`: The network is able to receive and respond to requests.
- `unavailable`: The network is not able to receive and respond to
requests for unknown reasons.
- `blocked`: The network is actively blocking requests based on the
user's geolocation. (This is specific to Infura.)
- `unknown`: We don't know whether the network can receive and respond
to requests, either because we haven't checked or we tried to check
and were unsuccessful.
This commit also changes how the network status is determined —
specifically, how many requests are used to determine that status, when
they occur, and whether they are awaited. Previously, the network
controller would make 2 to 3 requests during the course of running
`lookupNetwork`.
* First, if it was an Infura network, it would make a request for
`eth_blockNumber` to determine whether Infura was blocking requests or
not, then emit an appropriate event. This operation was not awaited.
* Then, regardless of the network, it would fetch the network ID via
`net_version`. This operation was awaited.
* Finally, regardless of the network, it would fetch the latest block
via `eth_getBlockByNumber`, then use the result to determine whether
the network supported EIP-1559. This operation was awaited.
Now:
* One fewer request is made, specifically `eth_blockNumber`, as we don't
need to make an extra request to determine whether Infura is blocking
requests; we can reuse `eth_getBlockByNumber`;
* All requests are awaited, which makes `lookupNetwork` run fully
in-band instead of partially out-of-band; and
* Both requests for `net_version` and `eth_getBlockByNumber` are
performed in parallel to make `lookupNetwork` run slightly faster.
2023-03-31 00:49:12 +02:00
|
|
|
networkId,
|
2021-03-01 16:15:42 +01:00
|
|
|
chainId,
|
|
|
|
);
|
2021-02-04 19:15:23 +01:00
|
|
|
const prevTxData = prevUnconfTxList[prevIndex] || {};
|
|
|
|
prevTx =
|
|
|
|
currentNetworkTxList.find(({ id }) => id === prevTxData.id) || {};
|
2020-01-13 18:02:54 +01:00
|
|
|
}
|
|
|
|
|
2023-02-01 06:54:18 +01:00
|
|
|
const unconfTxList = txHelper(
|
|
|
|
unapprovedTxs || {},
|
|
|
|
{},
|
|
|
|
{},
|
|
|
|
{},
|
NetworkController: Split `network` into `networkId` and `networkStatus` (#17556)
The `network` store of the network controller crams two types of data
into one place. It roughly tracks whether we have enough information to
make requests to the network and whether the network is capable of
receiving requests, but it also stores the ID of the network (as
obtained via `net_version`).
Generally we shouldn't be using the network ID for anything, as it has
been completely replaced by chain ID, which all custom RPC endpoints
have been required to support for over a year now. However, as the
network ID is used in various places within the extension codebase,
removing it entirely would be a non-trivial effort. So, minimally, this
commit splits `network` into two stores: `networkId` and
`networkStatus`. But it also expands the concept of network status.
Previously, the network was in one of two states: "loading" and
"not-loading". But now it can be in one of four states:
- `available`: The network is able to receive and respond to requests.
- `unavailable`: The network is not able to receive and respond to
requests for unknown reasons.
- `blocked`: The network is actively blocking requests based on the
user's geolocation. (This is specific to Infura.)
- `unknown`: We don't know whether the network can receive and respond
to requests, either because we haven't checked or we tried to check
and were unsuccessful.
This commit also changes how the network status is determined —
specifically, how many requests are used to determine that status, when
they occur, and whether they are awaited. Previously, the network
controller would make 2 to 3 requests during the course of running
`lookupNetwork`.
* First, if it was an Infura network, it would make a request for
`eth_blockNumber` to determine whether Infura was blocking requests or
not, then emit an appropriate event. This operation was not awaited.
* Then, regardless of the network, it would fetch the network ID via
`net_version`. This operation was awaited.
* Finally, regardless of the network, it would fetch the latest block
via `eth_getBlockByNumber`, then use the result to determine whether
the network supported EIP-1559. This operation was awaited.
Now:
* One fewer request is made, specifically `eth_blockNumber`, as we don't
need to make an extra request to determine whether Infura is blocking
requests; we can reuse `eth_getBlockByNumber`;
* All requests are awaited, which makes `lookupNetwork` run fully
in-band instead of partially out-of-band; and
* Both requests for `net_version` and `eth_getBlockByNumber` are
performed in parallel to make `lookupNetwork` run slightly faster.
2023-03-31 00:49:12 +02:00
|
|
|
networkId,
|
2023-02-01 06:54:18 +01:00
|
|
|
chainId,
|
|
|
|
);
|
2020-01-13 18:02:54 +01:00
|
|
|
|
2023-01-18 15:47:29 +01:00
|
|
|
if (prevTx && prevTx.status === TransactionStatus.dropped) {
|
2023-02-01 06:54:18 +01:00
|
|
|
dispatch(
|
2020-11-03 00:41:28 +01:00
|
|
|
actions.showModal({
|
|
|
|
name: 'TRANSACTION_CONFIRMED',
|
2023-02-01 06:54:18 +01:00
|
|
|
onSubmit: () => navigateToMostRecentOverviewPage(),
|
2020-11-03 00:41:28 +01:00
|
|
|
}),
|
2021-02-04 19:15:23 +01:00
|
|
|
);
|
|
|
|
return;
|
2020-01-13 18:02:54 +01:00
|
|
|
}
|
|
|
|
|
2023-02-01 06:54:18 +01:00
|
|
|
if (unconfTxList.length === 0 && !sendTo && unapprovedMessagesTotal === 0) {
|
|
|
|
navigateToMostRecentOverviewPage();
|
2020-01-13 18:02:54 +01:00
|
|
|
}
|
2017-03-22 23:14:33 +01:00
|
|
|
|
2023-02-01 06:54:18 +01:00
|
|
|
setPrevValues({ index, unapprovedTxs });
|
|
|
|
}, [
|
|
|
|
chainId,
|
|
|
|
currentNetworkTxList,
|
|
|
|
match,
|
NetworkController: Split `network` into `networkId` and `networkStatus` (#17556)
The `network` store of the network controller crams two types of data
into one place. It roughly tracks whether we have enough information to
make requests to the network and whether the network is capable of
receiving requests, but it also stores the ID of the network (as
obtained via `net_version`).
Generally we shouldn't be using the network ID for anything, as it has
been completely replaced by chain ID, which all custom RPC endpoints
have been required to support for over a year now. However, as the
network ID is used in various places within the extension codebase,
removing it entirely would be a non-trivial effort. So, minimally, this
commit splits `network` into two stores: `networkId` and
`networkStatus`. But it also expands the concept of network status.
Previously, the network was in one of two states: "loading" and
"not-loading". But now it can be in one of four states:
- `available`: The network is able to receive and respond to requests.
- `unavailable`: The network is not able to receive and respond to
requests for unknown reasons.
- `blocked`: The network is actively blocking requests based on the
user's geolocation. (This is specific to Infura.)
- `unknown`: We don't know whether the network can receive and respond
to requests, either because we haven't checked or we tried to check
and were unsuccessful.
This commit also changes how the network status is determined —
specifically, how many requests are used to determine that status, when
they occur, and whether they are awaited. Previously, the network
controller would make 2 to 3 requests during the course of running
`lookupNetwork`.
* First, if it was an Infura network, it would make a request for
`eth_blockNumber` to determine whether Infura was blocking requests or
not, then emit an appropriate event. This operation was not awaited.
* Then, regardless of the network, it would fetch the network ID via
`net_version`. This operation was awaited.
* Finally, regardless of the network, it would fetch the latest block
via `eth_getBlockByNumber`, then use the result to determine whether
the network supported EIP-1559. This operation was awaited.
Now:
* One fewer request is made, specifically `eth_blockNumber`, as we don't
need to make an extra request to determine whether Infura is blocking
requests; we can reuse `eth_getBlockByNumber`;
* All requests are awaited, which makes `lookupNetwork` run fully
in-band instead of partially out-of-band; and
* Both requests for `net_version` and `eth_getBlockByNumber` are
performed in parallel to make `lookupNetwork` run slightly faster.
2023-03-31 00:49:12 +02:00
|
|
|
networkId,
|
2023-02-01 06:54:18 +01:00
|
|
|
sendTo,
|
|
|
|
unapprovedMessagesTotal,
|
|
|
|
unapprovedTxs,
|
|
|
|
]);
|
|
|
|
|
|
|
|
const getTxData = () => {
|
|
|
|
const { params: { id: transactionId } = {} } = match;
|
|
|
|
|
|
|
|
const unconfTxList = txHelper(
|
|
|
|
unapprovedTxs || {},
|
|
|
|
unapprovedMsgs,
|
|
|
|
unapprovedPersonalMsgs,
|
|
|
|
unapprovedTypedMessages,
|
NetworkController: Split `network` into `networkId` and `networkStatus` (#17556)
The `network` store of the network controller crams two types of data
into one place. It roughly tracks whether we have enough information to
make requests to the network and whether the network is capable of
receiving requests, but it also stores the ID of the network (as
obtained via `net_version`).
Generally we shouldn't be using the network ID for anything, as it has
been completely replaced by chain ID, which all custom RPC endpoints
have been required to support for over a year now. However, as the
network ID is used in various places within the extension codebase,
removing it entirely would be a non-trivial effort. So, minimally, this
commit splits `network` into two stores: `networkId` and
`networkStatus`. But it also expands the concept of network status.
Previously, the network was in one of two states: "loading" and
"not-loading". But now it can be in one of four states:
- `available`: The network is able to receive and respond to requests.
- `unavailable`: The network is not able to receive and respond to
requests for unknown reasons.
- `blocked`: The network is actively blocking requests based on the
user's geolocation. (This is specific to Infura.)
- `unknown`: We don't know whether the network can receive and respond
to requests, either because we haven't checked or we tried to check
and were unsuccessful.
This commit also changes how the network status is determined —
specifically, how many requests are used to determine that status, when
they occur, and whether they are awaited. Previously, the network
controller would make 2 to 3 requests during the course of running
`lookupNetwork`.
* First, if it was an Infura network, it would make a request for
`eth_blockNumber` to determine whether Infura was blocking requests or
not, then emit an appropriate event. This operation was not awaited.
* Then, regardless of the network, it would fetch the network ID via
`net_version`. This operation was awaited.
* Finally, regardless of the network, it would fetch the latest block
via `eth_getBlockByNumber`, then use the result to determine whether
the network supported EIP-1559. This operation was awaited.
Now:
* One fewer request is made, specifically `eth_blockNumber`, as we don't
need to make an extra request to determine whether Infura is blocking
requests; we can reuse `eth_getBlockByNumber`;
* All requests are awaited, which makes `lookupNetwork` run fully
in-band instead of partially out-of-band; and
* Both requests for `net_version` and `eth_getBlockByNumber` are
performed in parallel to make `lookupNetwork` run slightly faster.
2023-03-31 00:49:12 +02:00
|
|
|
networkId,
|
2023-02-01 06:54:18 +01:00
|
|
|
chainId,
|
|
|
|
);
|
|
|
|
|
|
|
|
log.info(`rendering a combined ${unconfTxList.length} unconf msgs & txs`);
|
|
|
|
|
2023-06-01 11:48:07 +02:00
|
|
|
const unconfirmedTx = transactionId
|
2023-02-01 06:54:18 +01:00
|
|
|
? unconfTxList.find(({ id }) => `${id}` === transactionId)
|
|
|
|
: unconfTxList[index];
|
2023-06-01 11:48:07 +02:00
|
|
|
return cloneDeep(unconfirmedTx);
|
2023-02-01 06:54:18 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
const txData = getTxData() || {};
|
2017-02-23 23:23:45 +01:00
|
|
|
|
2023-02-01 06:54:18 +01:00
|
|
|
const { msgParams } = txData;
|
2023-07-21 11:28:54 +02:00
|
|
|
|
|
|
|
const targetSubjectMetadata = useSelector((state) =>
|
|
|
|
getTargetSubjectMetadata(state, msgParams?.origin),
|
|
|
|
);
|
|
|
|
|
2023-02-01 06:54:18 +01:00
|
|
|
if (!msgParams) {
|
|
|
|
return <Loading />;
|
|
|
|
}
|
2022-08-03 16:56:11 +02:00
|
|
|
|
2023-07-21 11:28:54 +02:00
|
|
|
const SigComponent = signatureSelect(txData, targetSubjectMetadata);
|
2023-02-01 06:54:18 +01:00
|
|
|
|
|
|
|
return (
|
|
|
|
<SigComponent
|
2023-07-07 10:05:58 +02:00
|
|
|
history={history}
|
2023-02-01 06:54:18 +01:00
|
|
|
txData={txData}
|
|
|
|
key={txData.id}
|
|
|
|
identities={identities}
|
|
|
|
currentCurrency={currentCurrency}
|
|
|
|
blockGasLimit={blockGasLimit}
|
2023-04-25 16:32:51 +02:00
|
|
|
///: BEGIN:ONLY_INCLUDE_IN(build-mmi)
|
2023-04-25 12:47:12 +02:00
|
|
|
selectedAccount={selectedAccount}
|
|
|
|
///: END:ONLY_INCLUDE_IN
|
2023-02-01 06:54:18 +01:00
|
|
|
/>
|
|
|
|
);
|
|
|
|
};
|
|
|
|
|
|
|
|
ConfirmTxScreen.propTypes = {
|
|
|
|
match: PropTypes.shape({
|
|
|
|
params: PropTypes.shape({
|
|
|
|
id: PropTypes.string,
|
|
|
|
}),
|
|
|
|
}),
|
|
|
|
};
|
2017-02-24 01:00:43 +01:00
|
|
|
|
2023-02-01 06:54:18 +01:00
|
|
|
export default withRouter(ConfirmTxScreen);
|