e66446edc3
The signing popup decided whether to show the message view or the transaction view by inspecting fields on the payload (`data`, `blockNumber`), while the background picks the signing behaviour from the message channel the request arrived on. Those two are independent and the payload comes from the dapp, so they can disagree. `RequestSign` becomes a discriminated union on `channel`, set by the background from the message type. Correlating the discriminant with the payload type means consumers narrow through `isExtrinsicRequest` rather than casting, so the display and the signing path can no longer drift apart. `Tabs.extrinsicSign` also rejects a payload carrying a truthy `data`, since that field has no meaning on that channel. Also branches the signing render on the request rather than on decoded state. Paging between two queued requests of different shapes could otherwise commit one frame using the previous request's decoded payload. Tests added under `signer channel` in `Extension.spec.ts`. |
||
|---|---|---|
| .. | ||
| src | ||
| package.json | ||
| README.md | ||
| tsconfig.build.json | ||
| tsconfig.spec.json | ||
@polkadot/extension-base
Functions, classes and other utilities used in @polkadot/extension. These include:
- background script handlers,
- message passing,
- scripts injected inside pages.
They are primarily meant to be used in @polkadot/extension, and can be broken without any notice to cater for @polkadot/extension's needs.
They are exported here if you wish to use part of them in the development of your
own extension. Don't forget to add process.env.EXTENSION_PREFIX to separate
ports and stores from the current extension's ones.