Conversation
feat: add Nibiru mainet and testnet
|
💼 Build Files |
WalkthroughAdds Nibiru and Nibiru Testnet with a Routescan activity provider; removes Canto, ZChains (ZCD), ProofOfPlayApex and related assets/token-list/dapp entries; updates multiple RPC/explorer endpoints and Kadena API; extends Changelly swap provider for RBTC floating-rate paths; widespread dependency/devtool bumps; introduces geo/wallet restriction checks and UI Restricted flow; several small UI and type/interface formatting tweaks. Changes
Sequence Diagram(s)sequenceDiagram
participant Ext as Extension (RoutescanActivity)
participant RS as Routescan API
participant Dec as decodeTx util
Note over Ext,RS: Fetch address txs → normalize → decode → Activity[]
Ext->>RS: GET /address/{addr}/txs?chainId={chainId}&limit=50&sort=desc
RS-->>Ext: [RoutescanTxType[]]
Ext->>Dec: decodeTx(rawTx)
Dec-->>Ext: decodedTxData
Ext-->>Caller: Activity[] (mapped from decoded + raw)
sequenceDiagram
participant Client as Swap caller
participant Changelly as Changelly provider
participant RPC as Changelly RPC
Note over Changelly: Dynamic RPC method selection based on RBTC presence
Client->>Changelly: getQuote(from, to, amount)
Changelly->>RPC: getFixRate OR getExchangeAmount (include amountFrom if floating)
RPC-->>Changelly: response (id/quote)
Changelly-->>Client: normalized quote
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Possibly related PRs
Suggested reviewers
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (4)
packages/keyring/package.json (1)
53-53: Verify vitest v4 compatibility before merge.Similar to other packages in this PR, vitest is being bumped from ^3.2.4 to ^4.0.6 (major version). Ensure all tests pass under vitest v4.
packages/request/package.json (1)
49-49: Verify vitest v4 compatibility before merge.Same vitest major version bump (^3.2.4 to ^4.0.6) as other packages. Ensure test suite passes under v4.
packages/signers/kadena/package.json (1)
48-48: Verify vitest v4 compatibility before merge.Same vitest major version bump as other packages. Ensure test suite passes under v4.
packages/signers/polkadot/package.json (1)
49-49: Verify vitest v4 compatibility before merge.Same vitest major version bump as other packages. Ensure test suite passes under v4.
🧹 Nitpick comments (1)
packages/hw-wallets/package.json (1)
55-73: Verify hardware wallet SDK compatibility.Multiple updates to hardware wallet integrations (@ledgerhq/, @trezor/connect) should be validated against supported device firmware versions and functionality. Confirm:
- Hardware wallet device discovery and signing still work correctly
- No breaking changes in Ledger/Trezor SDK APIs used by this package
- Test coverage includes USB transport edge cases if applicable
Would you like me to help create integration tests or validation scripts for these hardware wallet updates?
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (16)
package.json(1 hunks)packages/extension-bridge/package.json(2 hunks)packages/extension/package.json(5 hunks)packages/hw-wallets/package.json(3 hunks)packages/keyring/package.json(2 hunks)packages/name-resolution/package.json(3 hunks)packages/request/package.json(2 hunks)packages/signers/bitcoin/package.json(2 hunks)packages/signers/ethereum/package.json(2 hunks)packages/signers/kadena/package.json(2 hunks)packages/signers/massa/package.json(2 hunks)packages/signers/polkadot/package.json(2 hunks)packages/storage/package.json(2 hunks)packages/swap/package.json(3 hunks)packages/types/package.json(2 hunks)packages/utils/package.json(2 hunks)
🔇 Additional comments (18)
packages/storage/package.json (2)
30-44: Coordinate @types/node version across packages.Line 30 pins @types/node to ^22.19.0, but other packages in this PR use ^24.10.0 (e.g., packages/signers/ethereum, packages/signers/bitcoin). Confirm whether this inconsistency is intentional or whether all packages should converge on a single major version to ensure build compatibility.
45-45: Run the full test suite to validate vitest v4 compatibility.The v3 → v4 upgrade is a major version change with breaking changes around pool/worker configuration, config key names, test syntax, and mocking behavior. Static analysis of packages/storage shows no deprecated patterns and uses only v4-compatible vitest APIs (describe, it, expect). However, confirm compatibility by running
yarn testor the full workspace test suite after the upgrade to catch any runtime issues with mock behavior, snapshots, or coverage output.packages/signers/ethereum/package.json (2)
50-50: Verify vitest v4 compatibility for ethereum signer tests.Line 50 updates vitest to v4.0.6. Ensure existing tests and configurations are compatible with this major version or identify necessary migrations.
35-35: Note @types/node version difference.Line 35 uses @types/node ^24.10.0, while packages/storage uses ^22.19.0. Confirm this split is intentional or align versions across the workspace for consistency.
packages/utils/package.json (2)
49-49: Verify vitest v4 compatibility for utils package tests.Line 49 updates vitest to v4.0.6. Confirm test compatibility and any necessary configuration updates.
27-27: Update to @polkadot/util-crypto v13.5.7 is safe — no issues found.No known security vulnerabilities exist in v13.5.7. The sole change is a revert of pbkdf2Encode rounds to their previous value, and this function is not used anywhere in the codebase. The package is a runtime dependency in packages/utils and the patch update poses no risk to downstream consumers like packages/signers/massa.
packages/name-resolution/package.json (2)
40-40: Clarify intentionality of viem addition to devDependencies.Line 40 adds
"viem": "^2.38.6"as a new devDependency. Confirm whether this is intentional (perhaps for testing) or an accidental addition that should be removed or promoted to dependencies.
41-41: Verify vitest v4 compatibility for name-resolution tests.Line 41 updates vitest to v4.0.6. Confirm test compatibility and any necessary configuration updates.
packages/extension-bridge/package.json (2)
48-48: Verify @types/webextension-polyfill compatibility.Line 48 updates @types/webextension-polyfill to ^0.12.4. Confirm this is compatible with the runtime dependency webextension-polyfill ^0.12.0 (line 44) and the extension-bridge's Web Extension APIs.
51-51: The GitHub releases page for bumpp shows v10.1.0 as the latest release (from March 12, 2025), but the PR references v10.3.1. Let me search for more specific information about these package versions.Verification results show version availability but insufficient changelog documentation.
Type-fest v5.2.0 was published to npm 2 hours ago, and bumpp v10.3.1 was published 17 days ago. However, bumpp v10.3.1 has no corresponding GitHub release page (the latest GitHub release is v10.1.0 from March), and type-fest v5.2.0 is not yet documented on the official GitHub releases page.
Without accessible release notes or changelogs for these versions, it cannot be definitively verified whether they introduce breaking changes to version management or utility-type functionality. Review the npm package pages directly for specific changes in these versions before merging.
packages/signers/massa/package.json (2)
53-53: Verify vitest v4 compatibility for massa signer tests.Line 53 updates vitest to v4.0.6. Ensure test compatibility and identify any required migrations.
35-35: Verify @polkadot/util-crypto patch for massa package.Line 35 updates @polkadot/util-crypto to ^13.5.7 (same as packages/utils). Confirm this is compatible with the massa signer implementation.
packages/signers/bitcoin/package.json (2)
50-50: Verify vitest v4 compatibility for bitcoin signer tests.Line 50 updates vitest to v4.0.6. Confirm test compatibility and identify any necessary migrations.
35-35: Confirm intentional @types/node version split.Line 35 pins @types/node to ^24.10.0, consistent with packages/signers/ethereum but different from other packages (e.g., storage, utils, massa use ^22.19.0). If this split is intentional (e.g., due to Node.js compatibility requirements), document it; otherwise, align across the workspace.
package.json (1)
35-37: No breaking changes found. Both updates are safe.@commitlint/cli v20.1.0 introduced new features and a bug fix, with no breaking changes in this version. Note that v20.0.0 (the prior minor) introduced a breaking change: body-max-line-length now ignores lines containing URLs, but the current update from ^20.0.0 to ^20.1.0 is within the existing major version.
For @swc/core v1.14.0, no breaking changes are documented. The minor version bump (1.13.19 → 1.14.0) follows semantic versioning conventions for backwards-compatible updates. The caret ranges specified allow these updates safely.
packages/swap/package.json (1)
59-59: No breaking changes expected for this codebase's vitest upgrade.The migration from vitest ^3.2.4 to ^4.0.6 is safe. The vitest configuration is minimal (only test file patterns), tests use only basic, stable APIs (describe, it, expect, beforeEach), and none of the breaking changes from v4 apply: no advanced mocking, no pool/worker config, no custom environments, and no removed reporter configurations.
packages/extension/package.json (2)
141-141: Verify that vitest v4 tests pass in extension package withnpm test.Static analysis shows the vitest configuration (packages/extension/configs/vitest.config.mts) is clean—no deprecated options are present, the test setup is minimal, and the codebase doesn't rely on patterns that changed between v3 and v4 (coverage remapping, mock internals, or custom environments). However, only a full test run can confirm that all tests pass under vitest v4. Before merging, run
npm testin thepackages/extensiondirectory and verify no test failures occur.
26-90: Update verification claim about Rollup—it's v4.52.5, not a major ecosystem update.The review comment contains an inaccuracy: Rollup is pinned at ^4.52.5 (not Rollup 5, which doesn't exist yet). Vue 3.5.22 is confirmed as a non-breaking minor release.
However, Polkadot v16.4.9 does include breaking changes in metadata handling (version→versions, signedExtensions→transactionExtensions). While the codebase uses the @polkadot/extension-inject abstraction layer and high-level query APIs (e.g.,
api.query.system.account), which may shield it from direct breaking-change exposure, the actual runtime compatibility cannot be verified in this sandbox environment. The build commands fail due to missing node_modules state (environmental, not code-related).Manual verification is genuinely needed: test that the extension builds successfully, loads in all supported browsers, and performs Polkadot operations (signing, querying) without errors before merging.
fix: multiple node issues
feat: Nibiru network
Enable `RBTC` swaps using `Changelly` floating point API
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (2)
packages/extension/src/providers/ethereum/libs/activity-handlers/providers/routescan/types.ts (1)
14-14: Replaceanywithunknownor define a proper type.Using
anybypasses TypeScript's type safety. Consider usingunknownif the structure is truly unknown, or define a proper interface/type for the dapp object.Apply this diff:
- dapp?: any; + dapp?: unknown;packages/extension/src/providers/ethereum/libs/activity-handlers/providers/routescan/index.ts (1)
36-36: Handle undefinedtoaddress more defensively.The expression
tx.to?.id === '' ? null : tx.to?.idreturnsundefinedwhentx.tois nullish, which may not be the intended behavior. Consider explicitly returningnullfor consistency.Apply this diff:
- to: tx.to?.id === '' ? null : tx.to?.id, + to: !tx.to?.id || tx.to.id === '' ? null : tx.to.id,
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (23)
README.md(2 hunks)packages/extension/src/libs/dapp-list/index.ts(0 hunks)packages/extension/src/providers/ethereum/libs/activity-handlers/index.ts(2 hunks)packages/extension/src/providers/ethereum/libs/activity-handlers/providers/etherscan/configs.ts(0 hunks)packages/extension/src/providers/ethereum/libs/activity-handlers/providers/routescan/configs.ts(1 hunks)packages/extension/src/providers/ethereum/libs/activity-handlers/providers/routescan/index.ts(1 hunks)packages/extension/src/providers/ethereum/libs/activity-handlers/providers/routescan/types.ts(1 hunks)packages/extension/src/providers/ethereum/libs/assets-handlers/assetinfo-mew.ts(0 hunks)packages/extension/src/providers/ethereum/libs/assets-handlers/token-lists.ts(0 hunks)packages/extension/src/providers/ethereum/libs/assets-handlers/types/tokenbalance-mew.ts(0 hunks)packages/extension/src/providers/ethereum/networks/astr.ts(1 hunks)packages/extension/src/providers/ethereum/networks/ftm.ts(1 hunks)packages/extension/src/providers/ethereum/networks/index.ts(2 hunks)packages/extension/src/providers/ethereum/networks/nibiru-testnet.ts(1 hunks)packages/extension/src/providers/ethereum/networks/nibiru.ts(1 hunks)packages/extension/src/providers/ethereum/networks/okc.ts(0 hunks)packages/extension/src/providers/ethereum/networks/palm.ts(1 hunks)packages/extension/src/providers/ethereum/networks/pop-apex.ts(0 hunks)packages/extension/src/providers/ethereum/networks/xlayer.ts(1 hunks)packages/extension/src/providers/ethereum/networks/zcd.ts(0 hunks)packages/hw-wallets/src/ledger/ethereum/configs.ts(0 hunks)packages/swap/src/providers/changelly/index.ts(9 hunks)packages/types/src/networks.ts(2 hunks)
💤 Files with no reviewable changes (9)
- packages/extension/src/providers/ethereum/networks/zcd.ts
- packages/extension/src/providers/ethereum/libs/assets-handlers/token-lists.ts
- packages/extension/src/providers/ethereum/libs/activity-handlers/providers/etherscan/configs.ts
- packages/extension/src/libs/dapp-list/index.ts
- packages/extension/src/providers/ethereum/libs/assets-handlers/types/tokenbalance-mew.ts
- packages/hw-wallets/src/ledger/ethereum/configs.ts
- packages/extension/src/providers/ethereum/networks/pop-apex.ts
- packages/extension/src/providers/ethereum/libs/assets-handlers/assetinfo-mew.ts
- packages/extension/src/providers/ethereum/networks/okc.ts
🧰 Additional context used
🧬 Code graph analysis (4)
packages/extension/src/providers/ethereum/networks/nibiru-testnet.ts (2)
packages/extension/src/providers/ethereum/types/evm-network.ts (2)
EvmNetworkOptions(22-53)EvmNetwork(55-286)packages/extension/src/providers/ethereum/libs/activity-handlers/index.ts (1)
RoutescanActivity(17-17)
packages/extension/src/providers/ethereum/networks/nibiru.ts (2)
packages/extension/src/providers/ethereum/types/evm-network.ts (2)
EvmNetworkOptions(22-53)EvmNetwork(55-286)packages/extension/src/providers/ethereum/libs/activity-handlers/index.ts (1)
RoutescanActivity(17-17)
packages/extension/src/providers/ethereum/libs/activity-handlers/providers/routescan/index.ts (3)
packages/extension/src/providers/ethereum/libs/activity-handlers/providers/routescan/types.ts (1)
RoutescanTxType(1-32)packages/extension/src/providers/ethereum/types/evm-network.ts (1)
EvmNetwork(55-286)packages/extension/src/providers/ethereum/libs/transaction/decoder.ts (1)
decodeTx(98-98)
packages/swap/src/providers/changelly/index.ts (4)
packages/swap/src/types/index.ts (2)
TokenType(49-60)TokenTypeTo(78-80)packages/swap/src/providers/changelly/types.ts (4)
ChangellyApiGetFixRateParams(138-152)ChangellyApiGetFixRateResult(159-258)ChangellyApiGetFixRateForAmountResult(326-437)ChangellyApiCreateFixedRateTransactionResult(558-686)packages/utils/src/index.ts (1)
fromBase(49-49)packages/utils/src/units.ts (1)
fromBase(159-159)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: buildAll
- GitHub Check: test
🔇 Additional comments (18)
README.md (3)
122-123: LGTM!Nibiru and Nibiru Testnet entries are correctly positioned in alphabetical order within the "Currently Supported Chains" list, maintaining consistency with the list's organization.
91-91: Inconsistency: ZChains and ProofOfPlayApex entries remain in README despite claimed removal.The AI summary indicates that ZChains (line 110) and ProofOfPlayApex (line 91) were removed from the networks enum in the codebase. However, both entries are still present in this README without any change markers. If these networks are truly being deprecated and removed from the code, the README should be updated to reflect this change for consistency.
Please verify whether:
- ZChains and ProofOfPlayApex were actually removed from the networks enum in the code changes
- If removed, these entries should be deleted from the README to maintain alignment with the supported networks
- If not removed, the PR objectives/summary should be clarified
Also applies to: 110-110
231-231: LGTM!The addition of the "back to top" link at the end of the document maintains consistency with the pattern established throughout the README.
packages/extension/src/providers/ethereum/networks/astr.ts (1)
18-18: I'll use alternative verification methods sincewscatisn't available. Let me try Python-based WebSocket testing and gather information about the endpoint from the web.Let me search for the specific Astar endpoint documentation to confirm the endpoint format is correct.
No issues found. The endpoint change is correct and safe.
The new OnFinality Astar WebSocket endpoint
wss://astar.api.onfinality.io/public-wsis the official documented endpoint. OnFinality maintains 99.99% uptime and is a trusted infrastructure provider already supporting Polkadot, Kusama, Karura, Moonbeam and others, serving over 150 million JSON RPC requests daily. The configuration change is correct, uses secure WebSocket (wss://), and is backed by Astar's official partnership with OnFinality.packages/extension/src/providers/ethereum/networks/xlayer.ts (1)
18-18: Endpoint change verified and is safe to deploy.The HTTP RPC endpoint
https://xlayerrpc.okx.comis valid and working correctly. The application properly handles both HTTP and WebSocket protocols through dynamic provider recreation when protocol schemes differ. HTTP RPC endpoints are the predominant pattern across the network configurations in this codebase, and there are no WebSocket-specific dependencies for X Layer.packages/extension/src/providers/ethereum/networks/ftm.ts (1)
17-17: LGTM! RPC endpoint updated to official Fantom RPC.The change from WebSocket to HTTPS and switching to the official Fantom RPC endpoint is appropriate.
packages/extension/src/providers/ethereum/libs/activity-handlers/index.ts (1)
8-8: LGTM! RoutescanActivity properly integrated.The new Routescan activity provider is correctly imported and exported, following the same pattern as existing providers.
Also applies to: 17-17
packages/extension/src/providers/ethereum/libs/activity-handlers/providers/routescan/configs.ts (1)
1-8: LGTM! Routescan endpoints properly configured.The NetworkEndpoints mapping correctly associates Nibiru networks with their respective Routescan URLs using the NetworkNames enum.
packages/extension/src/providers/ethereum/networks/index.ts (1)
75-76: LGTM! Nibiru networks properly registered.The new Nibiru mainnet and testnet networks are correctly imported and exported, following the established pattern for network registration.
Also applies to: 160-161
packages/types/src/networks.ts (1)
108-109: LGTM! Network types properly extended.The NetworkNames and CoingeckoPlatform enums are correctly updated to include the new Nibiru networks, maintaining type safety across the codebase.
Also applies to: 182-182
packages/extension/src/providers/ethereum/networks/nibiru.ts (1)
1-26: Nibiru mainnet configuration verified and approved.The RPC endpoint is responsive and returns the correct chain ID (
0x1af4), confirming the network configuration is accurate. All required fields are properly set with RoutescanActivity provider integration in place.packages/extension/src/providers/ethereum/networks/nibiru-testnet.ts (1)
7-20: This review comment is incorrect—the omission of coingeckoID/coingeckoPlatform is a consistent pattern across all testnet configurations in the codebase, not an oversight.The RPC endpoint and chain ID are verified as correct. However, sampling testnet configurations (applayer-testnet.ts, coti-testnet.ts, cytonic-testnet.ts, rsk-testnet.ts) confirms that omitting these CoinGecko fields is the standard practice for all testnets, while mainnet configs include them. This deliberate distinction reflects that testnet tokens are typically not tracked on CoinGecko, making the suggested addition unnecessary and inconsistent with established patterns.
Likely an incorrect or invalid review comment.
packages/extension/src/providers/ethereum/libs/activity-handlers/providers/routescan/index.ts (1)
66-66: TheisIncominglogic is correct as implemented.The original concern assumes the handler receives unfiltered blockchain transactions. However, both the Routescan and Etherscan APIs pre-filter results to only return transactions involving the user's address. In the Routescan API, the query parameter explicitly includes
fromAddresses=${address}&toAddresses=${address}. Similarly, Etherscan'stxlistendpoint returns only transactions where the specified address is involved. Within this pre-filtered dataset,activity.from !== addresscorrectly identifies incoming transactions, since the only two possibilities are: the user is the sender (outgoing) or the user is the receiver (incoming).Likely an incorrect or invalid review comment.
packages/swap/src/providers/changelly/index.ts (5)
145-147: LGTM: RBTC floating-rate support enabled for destination tokens.The logic correctly allows RBTC tokens as swap destinations even when
fixRateEnabledis false, enabling floating-rate swaps for RBTC pairs.
435-442: LGTM: Amount correctly computed and passed to getMinMaxAmount.This ensures that when
getMinMaxAmountis called fromgetQuote, theamountparameter is always provided, which is necessary for RBTC floating-rate calculations usinggetExchangeAmount.
479-482: LGTM: Dynamic method selection for RBTC floating-rate quotes.The method correctly switches to
getExchangeAmountfor RBTC pairs, andparams.amountFromis properly populated fromquoteRequestAmountat lines 473-476.
694-698: LGTM: Dynamic transaction method selection for RBTC.The swap transaction correctly uses
createTransaction(floating-rate) instead ofcreateFixTransaction(fixed-rate) for RBTC pairs, consistent with the approach used ingetMinMaxAmountandgetQuote.
296-296: Verify: Potential undefinedamountFromfor RBTC floating-rate calls.The comment on line 324 states that
amountFromis "required" forgetExchangeAmount, butoptions.amountis optional and could beundefined. When RBTC is involved andoptions.amountis not provided,params.amountFromwill beundefined, potentially causing the API call to fail.Please verify:
- Can
getExchangeAmountwork without theamountFromparameter for retrieving min/max amounts?- If
amountFromis truly required, shouldgetMinMaxAmountvalidate thatoptions.amountis provided when RBTC pairs are involved?Also applies to: 311-325
packages/extension/src/providers/ethereum/libs/activity-handlers/providers/routescan/index.ts
Show resolved
Hide resolved
packages/extension/src/providers/ethereum/libs/activity-handlers/providers/routescan/index.ts
Show resolved
Hide resolved
packages/extension/src/providers/ethereum/libs/activity-handlers/providers/routescan/index.ts
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/extension/src/libs/backup-state/index.ts (1)
159-211: Add a clarifying comment explaining the exclusion of 'ed25519-kda' and fix the typo.The search confirms that Kadena is an active, fully-implemented provider, not a deprecated one. The exclusion of 'ed25519-kda' accounts during restore appears deliberate but lacks any documentation. Additionally, there's a typo: "exluded" should be "excluded".
Add a comment explaining the specific reason for excluding this signer type during restore (e.g., compatibility, security, or backward compatibility reasons). The suggested diff comment about deprecation is inaccurate; please provide the actual reason:
const mainWallet = await this.getMainWallet(); - const exludedSignerTypes = ['ed25519-kda']; + // TODO: Document why ed25519-kda accounts are excluded from restore + const excludedSignerTypes = ['ed25519-kda'];
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
packages/extension/src/libs/backup-state/index.ts(2 hunks)packages/extension/src/libs/utils/initialize-wallet.ts(0 hunks)packages/extension/src/providers/kadena/networks/index.ts(1 hunks)packages/extension/src/ui/action/views/lock-screen/index.vue(5 hunks)
💤 Files with no reviewable changes (1)
- packages/extension/src/libs/utils/initialize-wallet.ts
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: buildAll
- GitHub Check: test
- GitHub Check: test
🔇 Additional comments (2)
packages/extension/src/ui/action/views/lock-screen/index.vue (2)
3-20: LGTM! Formatting improvements to template.The template changes consolidate multi-line element attributes into a more concise format. All component bindings, v-show conditions, and event handlers remain functionally unchanged.
91-158: LGTM! Formatting improvements to styles.The CSS changes add consistent spacing between rule blocks and reformat the radial-gradient for better readability. No visual or functional changes result from these adjustments.
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
packages/extension/package.json(5 hunks)packages/extension/src/libs/backup-state/index.ts(2 hunks)packages/extension/src/libs/utils/initialize-wallet.ts(1 hunks)packages/extension/src/providers/ethereum/libs/assets-handlers/token-lists.ts(0 hunks)packages/extension/src/providers/kadena/networks/index.ts(1 hunks)packages/extension/src/providers/kadena/networks/kadena.ts(1 hunks)
💤 Files with no reviewable changes (1)
- packages/extension/src/providers/ethereum/libs/assets-handlers/token-lists.ts
✅ Files skipped from review due to trivial changes (1)
- packages/extension/src/libs/utils/initialize-wallet.ts
🚧 Files skipped from review as they are similar to previous changes (2)
- packages/extension/src/libs/backup-state/index.ts
- packages/extension/package.json
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: buildAll
- GitHub Check: test
- GitHub Check: test
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
packages/swap/src/providers/okx/index.ts (1)
505-508: Good defensive check, but add logging for observability.The guard clause correctly prevents a potential runtime error when
data.datais falsy. However, consider logging a warning when this fallback occurs, as it might indicate an API response format change or other issue that should be investigated.Apply this diff to add logging:
const data = await response.json(); - if (data.data) { + if (data.data && Array.isArray(data.data)) { return data.data; } + logger.warn( + `OKX tokens API returned unexpected response structure:`, + { hasData: !!data, hasDataData: !!data?.data, dataType: typeof data?.data } + ); return [];
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
packages/extension/src/ui/action/views/swap/index.vue(7 hunks)packages/swap/src/providers/okx/index.ts(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: buildAll
- GitHub Check: test
- GitHub Check: test
🔇 Additional comments (4)
packages/extension/src/ui/action/views/swap/index.vue (4)
13-56: Template formatting changes look functionally correct.All component declarations have been converted to single-line format. Props, events, and v-model bindings are preserved correctly, and the changes introduce no functional issues.
115-115: LGTM!The debug function formatting change is correct and has no functional impact.
259-262: LGTM!The string concatenation and ternary operator formatting changes are cosmetic and functionally correct.
Also applies to: 553-553, 740-741, 753-754
905-905: Minor visual adjustment to button area padding.The padding reduction from 32px to 28px is a small UI refinement that slightly tightens the spacing in the button area.
- Enhanced formatting and indentation in `eth-verify-transaction.vue` for better code clarity. - Streamlined the structure of `App.vue` by reducing unnecessary divs and improving component usage. - Updated `lock-screen/index.vue` to improve layout and readability. - Refined `restricted/index.vue` to enhance the user experience with clearer conditional rendering. - Improved `swap/index.vue` by organizing component props and events for better readability. - Enhanced `best-offer-list-item.vue` and `index.vue` for better structure and clarity. - Added geo-restriction checks in `onboard/App.vue` to improve user flow. - Standardized code style in `base58.ts`, `cross-browser.ts`, and various interface files for consistency. - Ensured all interface methods end with a semicolon for uniformity.
…rove eth_accounts method flow
Feat/restricted popup
feat: add provider names to swap
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/extension/src/ui/action/App.vue (1)
327-441: UnawaitedcheckAddressesmay surface unhandled rejections; restriction flag is “sticky”Two related points here:
- Unhandled rejections risk
setNetworkcallscheckAddresses(activeAccounts);withoutawait, whilecheckAddressesitself usesawait Promise.all(...). If anyisWalletRestricted(...)call rejects (network error, timeout, etc.), the rejection will bubble out ofcheckAddressesinto an unobserved promise, causing anunhandledrejectionat runtime.Consider either:
- Catching inside
checkAddresses, or- Awaiting it from
setNetworkwith a.catch:- checkAddresses(activeAccounts); + checkAddresses(activeAccounts).catch(console.error);or:
-const checkAddresses = async (activeAccounts: AccountsHeaderData['activeAccounts']) => { - const promises: Promise<boolean>[] = activeAccounts.map(ac => - isWalletRestricted(currentNetwork.value.displayAddress(ac.address)), - ); - await Promise.all(promises).then(results => { - if (results.includes(true)) foundRestrictedAddress.value = true; - }); -}; +const checkAddresses = async ( + activeAccounts: AccountsHeaderData['activeAccounts'], +) => { + try { + const results = await Promise.all( + activeAccounts.map(ac => + isWalletRestricted(currentNetwork.value.displayAddress(ac.address)), + ), + ); + if (results.includes(true)) foundRestrictedAddress.value = true; + } catch (e) { + console.error('Wallet restriction check failed', e); + } +};
- Restriction flag never resets
foundRestrictedAddressonly ever transitions fromfalsetotrueand is never reset, even when switching networks or accounts. That matches a “once any active account is restricted, the whole wallet session is blocked” model. If that’s intentional, this is fine. If restrictions are supposed to be per‑network or per‑current‑account, you’ll need to clear or recomputefoundRestrictedAddresson eachsetNetwork/selection change.
🧹 Nitpick comments (10)
packages/extension/src/providers/ethereum/methods/eth_accounts.ts (1)
23-24: LGTM! Clearer intent with explicit return.The change correctly separates the side-effect call from the return statement, which aligns with the
Promise<void>signature and makes the fire-and-forget pattern explicit.If
openOnboard()returns a Promise, consider adding.catch()to handle potential rejections:- throttledOpenOnboard(); + throttledOpenOnboard()?.catch(() => {/* onboarding will handle its own errors */}); return;packages/extension/src/ui/action/views/swap/views/swap-best-offer/components/swap-best-offer-block/index.vue (1)
3-7: Centralize PROVIDER_INFO lookup and add a safe fallbackYou’re indexing
PROVIDER_INFO[props.pickedTrade.provider]multiple times in the template; if a new provider ever ships without a corresponding entry, this will throw. Consider a single computed with a defensive fallback:@@ -import { imageLoadError } from '@/ui/action/utils/misc'; -import { PROVIDER_INFO } from '@enkryptcom/swap'; +import { imageLoadError } from '@/ui/action/utils/misc'; +import { PROVIDER_INFO } from '@enkryptcom/swap'; +import { computed } from 'vue'; @@ const props = defineProps<SwapBestOfferProps>(); @@ const ratio = computed(() => { const fromValue = new SwapToken(props.fromToken).getBalanceReadable(); const toValue = new SwapToken(props.toToken).getBalanceReadable(); return new BigNumber(toValue).div(new BigNumber(fromValue)); }); + +const providerInfo = computed(() => PROVIDER_INFO[props.pickedTrade.provider] ?? null);Template usage:
- <h3> - Best offer including network fee powered by - <img :src="PROVIDER_INFO[props.pickedTrade.provider].icon" /> - {{ PROVIDER_INFO[props.pickedTrade.provider].name }} - </h3> + <h3> + Best offer including network fee powered by + <template v-if="providerInfo"> + <img :src="providerInfo.icon" /> + {{ providerInfo.name }} + </template> + </h3> @@ - <p> - Provider: - <img - height="15px" - :src="PROVIDER_INFO[props.pickedTrade.provider].icon" - /> - {{ PROVIDER_INFO[props.pickedTrade.provider].name }} - </p> + <p> + Provider: + <template v-if="providerInfo"> + <img height="15px" :src="providerInfo.icon" /> + {{ providerInfo.name }} + </template> + <span v-else>Unknown</span> + </p>This removes duplication and makes the block resilient to mismatches between
pickedTrade.providerandPROVIDER_INFO.Also applies to: 48-55, 104-104, 195-198
packages/extension/src/ui/action/views/swap/views/swap-best-offer/components/swap-best-offer-block/components/best-offer-list-item.vue (1)
3-16: Provider display looks good; consider minor safety/consistency tweaksThe new provider UI is wired correctly and the
selecttyping improvement is nice. A couple of optional cleanups:
- If
ProviderNameis exported from the root@enkryptcom/swapentry, prefer that over@enkryptcom/swap/src/typesto avoid depending on internal paths.- You can mirror the block component and centralize the provider lookup with a computed plus a safer fallback:
-import { ProviderName } from '@enkryptcom/swap/src/types'; -import { PROVIDER_INFO } from '@enkryptcom/swap'; -import { PropType } from 'vue'; +import { ProviderName } from '@enkryptcom/swap/src/types'; // or '@enkryptcom/swap' if available +import { PROVIDER_INFO } from '@enkryptcom/swap'; +import { computed, PropType } from 'vue'; @@ -const props = defineProps({ +const props = defineProps({ @@ isChecked: { type: Boolean, default: () => { return false; }, }, }); + +const providerInfo = computed(() => + props.provider ? PROVIDER_INFO[props.provider] ?? null : null, +);Template:
- <div> - <img - v-if="PROVIDER_INFO[props.provider]" - :src="PROVIDER_INFO[props.provider].icon" - /> - </div> + <div> + <img v-if="providerInfo" :src="providerInfo.icon" /> + </div> @@ - <p> - {{ - props.provider - ? PROVIDER_INFO[props.provider].name - : 'Unknown Provider' - }} - </p> + <p> + {{ providerInfo?.name ?? 'Unknown Provider' }} + </p>This avoids repeating the lookup and gracefully handles any unexpected provider values.
Also applies to: 34-50, 100-103
packages/extension/src/ui/action/views/restricted/index.vue (1)
104-159: Consider scoping styles to avoid potential conflicts.The
<style lang="less">block is not scoped. The.settingsclass styles defined here (lines 107-159) could conflict with or override styles in other components that use the same class names.-<style lang="less"> +<style lang="less" scoped>If the
.settingsstyles need to target child components (likesettings-recovery), consider using:deep()selectors for specific overrides instead of leaving the entire block unscoped.packages/extension/src/libs/utils/screening.ts (2)
17-18: URL-encode the wallet address to prevent malformed requests.The
walletAddressparameter is interpolated directly into the URL without encoding. While Ethereum addresses are typically hex-safe, this could cause issues with addresses from other chains or malformed input.const result = await fetch( - `https://partners.mewapi.io/o/walletscreen?address=${walletAddress}`, + `https://partners.mewapi.io/o/walletscreen?address=${encodeURIComponent(walletAddress)}`, )
13-16: Consider adding cache bounds or TTL for long-running scenarios.The
walletCacheis unbounded and persists for the extension's lifetime. While unlikely to cause issues in typical usage, consider adding a maximum size or TTL to prevent unbounded growth in edge cases.packages/extension/src/ui/onboard/App.vue (1)
38-49: Simplify async handling: useawaitinstead of.then()in async function.The
onMountedcallback is markedasyncbut uses.then()internally. For consistency and readability, useawaitdirectly.onMounted(async () => { - isGeoRestricted().then(restricted => { - if (restricted) { - window.open( - 'https://help.myetherwallet.com/en/articles/12897302-geographic-restrictions-for-mew', - '_blank', - 'noopener', - ); - window.close(); - } - }); + const restricted = await isGeoRestricted(); + if (restricted) { + window.open( + 'https://help.myetherwallet.com/en/articles/12897302-geographic-restrictions-for-mew', + '_blank', + 'noopener', + ); + window.close(); + } });packages/extension/src/ui/action/App.vue (3)
281-321: Geo‑restricted path skips initialization and leavesisLoadingtrue — confirm intentWhen
isGeoRestricted()returns true, the mounted hook returns early without:
- Calling
init(),updatesStore.init(),menuStore.init(), orfetchAndSetRates().- Flipping
isLoadingtofalse.Because the template routes restricted users through the top‑level
v-ifand never renders theisLoading‑dependent branch, this is logically safe, but it does mean:
- Stores aren’t initialized in geo‑restricted sessions.
isLoadingremainstruefor the lifetime of that component instance.If the restricted flow is meant to be completely isolated from the rest of the popup, this is fine. If any downstream logic or other components rely on those stores being initialized even in restricted mode, consider explicitly setting
isLoading.value = falseand/or initializing the minimal subset of stores you still need before returning.
443-454:checkAddressesimplementation is fine but can be simplifiedWithin
checkAddresses, you don’t need the extra.thenonce you’re alreadyawait‑ing the promise:- await Promise.all(promises).then(results => { - if (results.includes(true)) foundRestrictedAddress.value = true; - }); + const results = await Promise.all(promises); + if (results.includes(true)) { + foundRestrictedAddress.value = true; + }This makes the control flow clearer and avoids mixing
awaitwith.thenin the same block.
531-538: Width classes for expanded/restricted could be de‑duplicated
.expandedand.restricted-containerboth setwidth: 800px, and.restricted-containeralso setsheight: 600pxwhich is already the default for.app. Functionally this is harmless, but you could simplify by having.restricted-containeronly carry semantic meaning (“restricted state”) and rely on.expanded/.appfor sizing:-.restricted-container { - width: 800px; - height: 600px; -} +.restricted-container { + // semantic hook for restricted state; sizing handled by .app/.expanded +}Not required, but would reduce CSS duplication.
Also applies to: 618-621
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (7)
packages/swap/src/common/icons/0x-logo.pngis excluded by!**/*.pngpackages/swap/src/common/icons/1inch-logo.pngis excluded by!**/*.pngpackages/swap/src/common/icons/changelly-logo.pngis excluded by!**/*.pngpackages/swap/src/common/icons/jupiter-logo.pngis excluded by!**/*.pngpackages/swap/src/common/icons/okx-logo.pngis excluded by!**/*.pngpackages/swap/src/common/icons/paraswap-logo.pngis excluded by!**/*.pngpackages/swap/src/common/icons/rango-logo.pngis excluded by!**/*.png
📒 Files selected for processing (27)
packages/extension/src/libs/background/index.ts(5 hunks)packages/extension/src/libs/utils/screening.ts(1 hunks)packages/extension/src/providers/ethereum/methods/eth_accounts.ts(1 hunks)packages/extension/src/providers/ethereum/ui/eth-verify-transaction.vue(1 hunks)packages/extension/src/ui/action/App.vue(10 hunks)packages/extension/src/ui/action/views/lock-screen/components/lock-screen-password-input.vue(1 hunks)packages/extension/src/ui/action/views/lock-screen/index.vue(4 hunks)packages/extension/src/ui/action/views/restricted/index.vue(1 hunks)packages/extension/src/ui/action/views/settings/components/settings-inner-header.vue(2 hunks)packages/extension/src/ui/action/views/settings/views/settings-recovery/index.vue(2 hunks)packages/extension/src/ui/action/views/swap/index.vue(1 hunks)packages/extension/src/ui/action/views/swap/views/swap-best-offer/components/swap-best-offer-block/components/best-offer-list-item.vue(3 hunks)packages/extension/src/ui/action/views/swap/views/swap-best-offer/components/swap-best-offer-block/components/best-offer-list.vue(1 hunks)packages/extension/src/ui/action/views/swap/views/swap-best-offer/components/swap-best-offer-block/index.vue(4 hunks)packages/extension/src/ui/onboard/App.vue(3 hunks)packages/signers/massa/src/crypto/base58.ts(1 hunks)packages/signers/massa/src/crypto/cross-browser.ts(5 hunks)packages/signers/massa/src/crypto/interfaces/hasher.ts(1 hunks)packages/signers/massa/src/crypto/interfaces/sealer.ts(1 hunks)packages/signers/massa/src/crypto/interfaces/serializer.ts(1 hunks)packages/signers/massa/src/crypto/interfaces/signer.ts(1 hunks)packages/signers/massa/src/crypto/interfaces/versioner.ts(1 hunks)packages/swap/src/common/icons/index.d.ts(1 hunks)packages/swap/src/configs.ts(2 hunks)packages/swap/src/index.ts(2 hunks)packages/swap/src/types/index.ts(1 hunks)packages/swap/tsconfig.json(1 hunks)
✅ Files skipped from review due to trivial changes (4)
- packages/signers/massa/src/crypto/cross-browser.ts
- packages/extension/src/ui/action/views/lock-screen/components/lock-screen-password-input.vue
- packages/signers/massa/src/crypto/interfaces/hasher.ts
- packages/signers/massa/src/crypto/interfaces/signer.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/extension/src/providers/ethereum/ui/eth-verify-transaction.vue
🧰 Additional context used
🧬 Code graph analysis (3)
packages/signers/massa/src/crypto/base58.ts (1)
packages/signers/massa/src/crypto/interfaces/serializer.ts (1)
Serializer(2-5)
packages/extension/src/libs/background/index.ts (2)
packages/extension/src/libs/utils/screening.ts (1)
isGeoRestricted(32-32)packages/extension/src/libs/error/index.ts (1)
getCustomError(27-33)
packages/signers/massa/src/crypto/interfaces/versioner.ts (2)
packages/extension/src/providers/solana/libs/wallet-standard/wallet.ts (1)
version(69-71)packages/extension/src/ui/action/types/updates.ts (1)
Version(3-10)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: buildAll
- GitHub Check: test
- GitHub Check: test
🔇 Additional comments (27)
packages/signers/massa/src/crypto/base58.ts (2)
1-2: LGTM!Import statements are correct. The
bs58checklibrary is the appropriate choice for Base58Check encoding/decoding used in cryptocurrency address formats.
7-16: LGTM!The
Base58class correctly implements theSerializerinterface. Thebs58check.encode()andbs58check.decode()methods are used appropriately for Base58Check serialization, which includes a checksum for data integrity—suitable for cryptocurrency address encoding in Massa.packages/signers/massa/src/crypto/interfaces/sealer.ts (1)
4-6: Semicolon-only style update; interface contract unchangedThe added semicolons on
sealandunsealare purely stylistic, align with interface style elsewhere, and do not affect types or behavior.packages/signers/massa/src/crypto/interfaces/versioner.ts (1)
3-4: Versioner method punctuation normalizedAdding semicolons to
attachandextractkeeps the public API identical while matching interface style; no issues.packages/signers/massa/src/crypto/interfaces/serializer.ts (1)
3-4: Serializer interface formatting onlyThe added semicolons are a no-op for behavior and keep the interface consistent with surrounding code.
packages/swap/tsconfig.json (1)
18-18: LGTM!Adding
src/**/*.pngto the include pattern correctly enables TypeScript to process PNG file imports alongside the ambient module declaration. This is a standard approach for handling asset imports in TypeScript projects.packages/swap/src/common/icons/index.d.ts (1)
1-4: LGTM!Standard ambient module declaration for PNG imports. The
export = valuesyntax works well with the project'sesModuleInteropandallowSyntheticDefaultImportssettings.packages/swap/src/types/index.ts (1)
135-146: LGTM!The
ProviderNameProperenum is well-structured with keys matching the existingProviderNameenum. This provides a clean separation between internal identifiers and human-readable display names for UI purposes.packages/swap/src/configs.ts (1)
24-60: LGTM!The
PROVIDER_INFOmapping is well-typed usingRecord<ProviderName, ...>, which ensures TypeScript will flag any missing provider entries. All eight providers are correctly mapped with their respective display names and icons.packages/swap/src/index.ts (2)
5-5: LGTM!Clean import of
PROVIDER_INFOalongside existing config imports.
280-280: LGTM!Properly exposes
PROVIDER_INFOas part of the package's public API, enabling consumers to access provider metadata (names and icons) for UI rendering.packages/extension/src/ui/action/views/swap/index.vue (1)
960-980: Bottom button bar padding change looks safeReducing
.swap__buttonspadding from 32px to 28px is a purely visual adjustment and shouldn’t affect behavior; just confirm it still aligns with the design spec on smaller heights.packages/extension/src/ui/action/views/swap/views/swap-best-offer/components/swap-best-offer-block/components/best-offer-list.vue (1)
4-13: Provider prop wiring is consistent with existing trade shapePassing
:provider="trade.provider"down tobest-offer-list-itemaligns with howtrade.provideris already used for keys and selection; no additional issues spotted.packages/extension/src/ui/action/views/lock-screen/index.vue (1)
109-181: LGTM!The style block changes are purely formatting adjustments (whitespace/blank line normalization). No functional impact.
packages/extension/src/ui/action/views/restricted/index.vue (2)
84-93: Good security practice: clearing sensitive mnemonic data on close.The
closeMnemonicfunction properly clears the mnemonic data when the overlay is dismissed, preventing sensitive recovery phrase data from lingering in memory unnecessarily.
1-48: LGTM!The template structure effectively separates the main restricted page from the mnemonic overlay. The conditional rendering and modal flow logic are well-organized.
packages/extension/src/libs/utils/screening.ts (1)
7-10: Verify: fail-open behavior is intentional.Both functions return
false(not restricted) when the API is unavailable or returns an error. This "fail-open" approach prioritizes user access over strict enforcement. Please confirm this is the intended behavior, as it means restrictions won't apply during API outages.Also applies to: 24-27
packages/extension/src/libs/background/index.ts (3)
56-59: Note: geo-restriction check is asynchronous and non-blocking.The constructor fires
isGeoRestricted()without awaiting, allowing the handler to initialize immediately. This means requests arriving before the check completes will not be geo-blocked (line 109 checks#geoRestricted !== undefined). This appears intentional to avoid startup delays, but worth confirming this brief window of unrestricted access is acceptable.
109-117: LGTM!The geo-restriction guard correctly checks that the restriction status is both determined (
!== undefined) and positive before blocking. The error message includes a helpful URL for users to understand why they're blocked.
86-98: Good practice: re-checking geo restriction on window events.Re-evaluating the geo restriction status on
newWindowInitandnewWindowUnloadevents helps catch changes in the user's network state (e.g., VPN changes).packages/extension/src/ui/onboard/App.vue (2)
41-46: Verify:window.close()behavior in extension onboarding context.
window.close()may not work in all browser contexts (e.g., tabs not opened by script). In the extension's onboarding tab, this should typically work, but consider adding a fallback or user instruction if the window doesn't close.
11-14: LGTM!Template and CSS formatting adjustments improve readability without functional changes.
Also applies to: 75-75
packages/extension/src/ui/action/App.vue (3)
2-8: Restricted gating takes precedence over main app contentThe
v-if="foundRestrictedAddress || geoRestricted"wrapper cleanly short‑circuits into theRestrictedview and keeps the rest of the app (including loading/content) out of the DOM. This is a sensible compliance guard and theisWalletInitializedflag gives the restricted view enough context to render appropriate messaging.
9-33: Loading vs content toggle remains coherent with the new restricted flowThe
v-elsebranch still usesisLoadingto switch between<swap-looking-animation />and the main content, and that entire branch is suppressed when the restricted view is active. This keeps the pre‑existing UX intact for non‑restricted users while ensuring restricted users never see the normal popup UI.
124-168: Geo/wallet restriction state is integrated cleanly into the composition stateThe addition of
Restricted,isGeoRestricted, andisWalletRestrictedalong withgeoRestrictedandisWalletInitializedrefs is straightforward and keeps all screening‑related state co‑located. Defaults are conservative (non‑restricted, non‑initialized) and existing flows are preserved unless restrictions are detected.packages/extension/src/ui/action/views/settings/components/settings-inner-header.vue (1)
3-5: Configurable back button with backward‑compatible defaultConditioning the back button on
hasBackand defaulting the prop totruepreserves current behavior while allowing views like recovery to hide the back control when needed. The prop wiring is minimal and consistent with existing boolean flags.Also applies to: 27-30
packages/extension/src/ui/action/views/settings/views/settings-recovery/index.vue (1)
3-7:hasBackis plumbed through cleanly and stays backward‑compatibleExposing a local
hasBackprop and forwarding it toSettingsInnerHeaderkeeps the header behavior configurable per‑view while maintaining existing default behavior (true). This aligns well with the new header prop and doesn’t affect the mnemonic/recovery logic.Also applies to: 49-53
4 participants
Summary by CodeRabbit
Chores
New Features
Maintenance
UI / Security
✏️ Tip: You can customize this high-level summary in your review settings.