[pull] main from MetaMask:main#573
Merged
Merged
Conversation
…compatible (#26915) <!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until the template has been completely filled out, and PR status checks have passed at least once. --> ## **Description** Remove BIP-44 feature flag mock from Ethereum Provider Snap tests so they run with production settings. #24151 https://consensyssoftware.atlassian.net/browse/MMQA-1511 ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> CHANGELOG entry: null ## **Related issues** Fixes: ## **Manual testing steps** ```gherkin Feature: my feature name Scenario: user [verb for user action] Given [describe expected initial app state] When user [verb for user action] Then [describe expected outcome] ``` ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** <!-- [screenshots/recordings] --> ## **Pre-merge author checklist** - [ ] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [ ] I've completed the PR template to the best of my ability - [ ] I've included tests if applicable - [ ] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [ ] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. ## **Pre-merge reviewer checklist** - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Low risk: only adjusts smoke-test feature flag mocking, with no production code changes; main impact is potential test behavior drift if the test implicitly relied on the disabled flag. > > **Overview** > Updates the Ethereum Provider Snap smoke test to run with more production-like remote feature flag settings by **removing the explicit override that disabled** `remoteFeatureMultichainAccountsAccountDetailsV2`. > > The test now mocks only `confirmationFeatureFlags` (plus genesis block stubs) when calling `setupRemoteFeatureFlagsMock`, and drops the unused feature-flag import. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 157043e. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY -->
<!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until the template has been completely filled out, and PR status checks have passed at least once. --> ## **Description** Port extension name-lookup test to mobile for increased coverage. The PR adjusts a few shared utilities to make the tests more stable and enable the flow tested in this test. ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> CHANGELOG entry: null ## **Related issues** Closes: MetaMask/snaps#3572 <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Low risk: changes are limited to Detox E2E test code and test selectors, with a small tap-stability tweak that could affect test flakiness but not app behavior. > > **Overview** > Adds a new smoke E2E test (`test-snap-name-lookup.spec.ts`) that installs the **Name Lookup** test snap and verifies a domain recipient resolves to the expected address during the send/confirmation flow. > > Extends test infrastructure to support the scenario by adding the `connectNameLookupButton` selector, adding a `tapAdvancedDetails()` helper on `TransactionConfirmView`, and making `RedesignedSendView.pressReviewButton()` use `checkStability` when tapping. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit d3d21a0. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY -->
<!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until the template has been completely filled out, and PR status checks have passed at least once. --> ## **Description** https://consensyssoftware.atlassian.net/browse/RWDS-1055 Handle 403 auth error with retry first before showing error banner. Two major changes are made: 1. Data Service: Centralized 403 detection in `makeRequest` and throws AuthorizationFailedError for controller 2. Controller: `withAuthRetry` Wrapper to performSilentAuth before throwing error, to suppress error banner during re-auth <!-- Write a short description of the changes included in this pull request, also include relevant motivation and context. Have in mind the following questions: 1. What is the reason for the change? 4. What is the improvement/solution? --> ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> CHANGELOG entry: null ## **Related issues** Fixes: ## **Manual testing steps** ```gherkin Feature: my feature name Scenario: user [verb for user action] Given [describe expected initial app state] When user [verb for user action] Then [describe expected outcome] ``` ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** <!-- [screenshots/recordings] --> ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. ## **Pre-merge reviewer checklist** - [x] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [x] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Touches rewards authentication/session-token handling and retries multiple API-backed controller methods, which can impact user state and caching if the retry/reauth flow misbehaves. Changes are scoped to rewards and covered by updated/new tests, reducing rollout risk. > > **Overview** > Adds centralized 403 handling for authenticated Rewards API calls: `RewardsDataService.makeRequest` now throws `AuthorizationFailedError` when a subscription-scoped request returns 403 (and removes prior message-based detection in `getSeasonStatus`). > > Updates `RewardsController` to wrap several subscription-authenticated operations (`getSeasonStatus`, points events, referral details, boosts, unlocked rewards, snapshots, claim/apply/opt-out/bonus-code validation) in a new `#withAuthRetry` helper that triggers a silent re-auth (`#performReauthForSubscription`) and retries the original call once. Concurrent 403s for the same subscription are coalesced via a per-subscription promise map, and failed reauth now invalidates subscription caches/state before rethrowing. > > Tests are adjusted to match the new error messages/logging and add coverage for 403 detection in the data service plus reauth+retry behavior (including active boosts) and non-403 no-retry behavior. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 7f2b4b2. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY -->
…non-EVM network switch (#26965) ## **Description** When switching from a Non-EVM network (e.g. Solana, Bitcoin) to All Popular Networks, the Receive QR modal in EVM token details was displaying the Non-EVM account address instead of the correct EVM (0x) address. The root cause was in `useTokenActions.ts`: the `onReceive` handler only called `getAccountByScope` for non-EVM tokens, falling back to `selectedInternalAccount` for EVM tokens. Since `selectedInternalAccount` is the globally selected account and remains stale from the previous non-EVM network selection, the wrong address was passed to the QR modal. The fix aligns `onReceive` with the pattern already used correctly in `useTokenTransactions.ts` — always resolving the account via `getAccountByScope` with the CAIP-formatted chain ID, falling back to `selectedInternalAccount` only if no scoped account is found. ## **Changelog** CHANGELOG entry: Fixed a bug where the Receive address in EVM token details showed a Non-EVM address after switching from a Non-EVM network. ## **Related issues** Fixes: #26793 ## **Manual testing steps** ```gherkin Feature: Receive address in token details Scenario: user switches from a Non-EVM network to an EVM network and opens Receive Given the user has both a Solana account and an Ethereum account in the same group And the user is viewing a Solana token and opens the Receive modal And the user navigates back and switches to All Popular Networks When the user opens an Ethereum token details and taps Receive Then the QR modal should display the correct 0x Ethereum address And the address should NOT be a base58 Solana address ``` ## **Screenshots/Recordings** `~` ### **Before** https://github.com/user-attachments/assets/0a26d5be-fbc6-4275-b27a-ff2c094e395f ### **After** https://github.com/user-attachments/assets/efee1b40-26cc-438c-9fd6-7621443486d4 ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. ## **Pre-merge reviewer checklist** - [x] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [x] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Touches the address-selection logic used when displaying the Receive QR modal; a wrong scope/CAIP conversion could show an incorrect address for some networks. The change is small and localized, with a fallback to the previously selected internal account. > > **Overview** > **Fixes a Receive-address scoping bug in Token Details.** The `onReceive` handler now always resolves the account via `selectSelectedInternalAccountByScope` using a CAIP-formatted `token.chainId`, falling back to `selectedInternalAccount` only if no scoped account exists. > > This prevents the Receive QR sheet from showing a stale non-EVM address when opening an EVM token after switching networks. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 4202b64. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY -->
## **Description** Introduces a reusable, generic `AdvancedChart` component built on [TradingView Advanced Charts](https://www.tradingview.com/charting-library-docs/latest/getting_started/) rendered inside a WebView. This component is designed to be consumed by multiple features (Token Details, Perps, etc.) with a composable props API, each consumer uses only the props it needs. This PR is just for testing this new component: #26465 ### What's included **Core component (`AdvancedChart.tsx`)** - WebView-based TradingView charting widget with full candlestick/OHLCV support - Composable props API: `ohlcvData`, `indicators`, `positionLines`, `showVolume`, `chartType`, etc. - Imperative ref handle for one-off actions (`addIndicator`, `removeIndicator`, `setChartType`, `reset`) - Bidirectional message protocol between React Native and WebView (`RNToWebViewMessage` / `WebViewToRNMessage`) - Error handling with retry-on-recovery and loading states - Dynamic resolution detection: automatically adapts bar width based on incoming data interval **WebView logic (`webview/chartLogic.js`)** - Custom TradingView datafeed implementation (`onReady`, `getBars`, `subscribeBars`, `unsubscribeBars`) - Widget lifecycle management: creates, destroys, and recreates the TradingView widget when the data resolution changes (e.g., switching from 1D to 1H) - Volume study with themed colors - Technical indicator support (MACD, RSI, MA200) via `createStudy` / `removeStudy` - Position lines overlay (entry, take-profit, stop-loss, liquidation) for Perps use case - Real-time bar updates via `realtimeCallback` - Crosshair tracking with bar-snapping for OHLC data forwarding - All unnecessary TradingView UI elements disabled via `disabled_features` **HTML template (`AdvancedChartTemplate.ts`)** - Generates WebView HTML with injected theme colors and feature flags - Configurable `CHARTING_LIBRARY_URL` for local dev (`localhost:8000`) or S3 deployment **Time range selector (`TimeRangeSelector.tsx`)** - Time range options: 1H, 1D, 1W, 1M, YTD, ALL - Each range maps to a Hyperliquid candle interval and count (e.g., 1H → 1m candles × 60) - Exports `TIME_RANGE_CONFIGS` for consumer data fetching **Indicator toggle (`IndicatorToggle.tsx`)** - Toggle buttons for MACD, RSI, MA200 technical indicators - Designed for Token Details chart header ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> CHANGELOG entry: null ## **Related issues** Fixes: ## **Manual testing steps** ```gherkin Feature: my feature name Scenario: user [verb for user action] Given [describe expected initial app state] When user [verb for user action] Then [describe expected outcome] ``` ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** <!-- [screenshots/recordings] --> ## **Pre-merge author checklist** - [ ] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [ ] I've completed the PR template to the best of my ability - [ ] I've included tests if applicable - [ ] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [ ] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. ## **Pre-merge reviewer checklist** - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Introduces a new WebView-based chart surface that loads the TradingView library from a configurable CDN and bridges messages between JS and React Native, which carries moderate risk around WebView security/CSP correctness and runtime stability. > > **Overview** > Adds a reusable `AdvancedChart` component that renders TradingView Advanced Charts in a `WebView`, with a typed RN↔WebView message protocol to sync OHLCV data, realtime ticks, indicators, chart type, volume visibility, and optional position-line overlays. > > Introduces a generated WebView script pipeline (`webview/chartLogic.js` → `chartLogicString.ts` via `syncChartLogic.js`) plus an HTML template (`AdvancedChartTemplate.ts`) that injects theme/feature config, CSP, and a configurable charting-library base URL (`MM_CHARTING_LIBRARY_URL`). > > Adds a `TimeRangeSelector` utility component with predefined range→interval/count mappings, updates `.eslintignore` for the WebView scripts, and includes unit tests covering chart message/ref behavior and the selector. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 3785ec1. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY -->
<!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until the template has been completely filled out, and PR status checks have passed at least once. --> ## **Description** - Adds a unified gesture layer using the **Strategy pattern** (`GestureStrategy` interface with `DetoxGestureStrategy` and `AppiumGestureStrategy` implementations), allowing page objects to execute gestures without knowing which framework is running - Adds `UnifiedGestures` static facade and `encapsulatedAction()` helper for the rare cases where Detox and Appium need structurally different flows - Centralizes test documentation into `tests/docs/` alongside existing guides (`MOCKING.md`, `CONTROLLER_MOCKING.md`, etc.) ## Changes | File | What | |------|------| | `tests/framework/GestureStrategy.ts` | New — `GestureStrategy` interface + `DetoxGestureStrategy` and `AppiumGestureStrategy` implementations | | `tests/framework/UnifiedGestures.ts` | New — Static facade that delegates to the active strategy | | `tests/framework/encapsulatedAction.ts` | New — Helper for framework-branching action logic | | `tests/docs/UNIFIED_GESTURES_MIGRATION.md` | New — Migration guide for adopting `UnifiedGestures` in page objects | | `tests/docs/UNIFIED_E2E_ARCHITECTURE.md` | Moved from `tests/framework/` (also fixed filename typo: `ARCHIITECTURE` → `ARCHITECTURE`) | <!-- Write a short description of the changes included in this pull request, also include relevant motivation and context. Have in mind the following questions: 1. What is the reason for the change? 2. What is the improvement/solution? --> ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> CHANGELOG entry: ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/MMQA-1544 ## **Manual testing steps** N/A ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** N/A <!-- [screenshots/recordings] --> ### **After** N/A <!-- [screenshots/recordings] --> ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. ## **Pre-merge reviewer checklist** - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Adds new test-only abstraction layers and helpers without changing existing `Gestures` behavior; risk is mainly limited to new unified APIs and their validation/edge-case handling (e.g., `scrollToElement` matcher type checks and `tapAtIndex` bounds checks). > > **Overview** > Adds a new **framework-agnostic gesture API** via `UnifiedGestures`, backed by a `GestureStrategy` interface with `DetoxGestureStrategy` (delegates to existing `Gestures` while mapping `timeout`/`description`) and `AppiumGestureStrategy` (delegates to `PlaywrightElement`/`PlaywrightGestures`). > > Extends Appium gesture support with a native-touch `PlaywrightGestures.dblTap`, adds an `encapsulatedAction()` escape hatch for framework-divergent flows, and exports the new APIs from `tests/framework/index.ts`. > > Adds unit coverage for key strategy behaviors (`scrollToElement` forwarding + matcher validation, `dblTap` delegation, and `tapAtIndex` array/index handling) and includes a migration guide under `tests/docs/`. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 12296cc. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY -->
…ng (#26415) Previously, the QR signing flow only called PermissionsAndroid.check() to verify camera access. When a user had selected "only this time" for camera permission, Android revokes the grant on app background. On next launch, check() returns false, disabling the "Get signature" button with no way to re-grant permission from within the app. Now both useCamera.ts and QRSigningDetails.tsx follow a check-then-request pattern: if check() returns false, request() is called to trigger the system permission dialog, matching the behavior of the "Add QR wallet" flow which already used requestPermission() from react-native-vision-camera. Fixes #26115 <!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until the template has been completely filled out, and PR status checks have passed at least once. --> ## **Description** <!-- Write a short description of the changes included in this pull request, also include relevant motivation and context. Have in mind the following questions: 1. What is the reason for the change? 2. What is the improvement/solution? --> ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> CHANGELOG entry: fix camera permission `allow once` didn't show the camera popup in android. ## **Related issues** Fixes: #26115 ## **Manual testing steps** ```gherkin Feature: my feature name Scenario: user [verb for user action] Given [describe expected initial app state] When user [verb for user action] Then [describe expected outcome] ``` ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** <!-- [screenshots/recordings] --> ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. ## **Pre-merge reviewer checklist** - [x] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [x] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Changes camera-permission gating in the QR signing flow (always enabling the confirm button and moving permission handling into `AnimatedQRScannerModal`), which can affect Android UX and scanning availability if the permission lifecycle has edge cases. > > **Overview** > Fixes Android QR transaction signing when camera permission is revoked after backgrounding by **moving permission handling fully into** `AnimatedQRScannerModal`. > > The scanner now re-requests permission when the app returns to the foreground and, if permission remains denied, keeps the modal open showing a *no-permission* state with an **Open Settings** button (`Linking.openSettings`) instead of immediately erroring out. > > Removes pre-check/pre-request Android permission logic (`PermissionsAndroid`) from `QRSigningDetails`/`useCamera`, so the "Get signature"/confirm button is no longer disabled for camera permission reasons; related props and tests are updated, plus new `qr_scanner.open_settings` translations and small smoke-test assertion/scrolling robustness tweaks. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit eede7fe. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY --> --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com> Co-authored-by: Xiaoming Wang <dawnseeker8@users.noreply.github.com> Co-authored-by: Olivier-BB <Olivier-BB@users.noreply.github.com>
<!--
Please submit this PR as a draft initially.
Do not mark it as "Ready for review" until the template has been
completely filled out, and PR status checks have passed at least once.
-->
## **Description**
Small text update to the entry card disclaimer.
## **Changelog**
<!--
If this PR is not End-User-Facing and should not show up in the
CHANGELOG, you can choose to either:
1. Write `CHANGELOG entry: null`
2. Label with `no-changelog`
If this PR is End-User-Facing, please write a short User-Facing
description in the past tense like:
`CHANGELOG entry: Added a new tab for users to see their NFTs`
`CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker`
(This helps the Release Engineer do their job more quickly and
accurately)
-->
CHANGELOG entry: null
## **Related issues**
Fixes:
## **Manual testing steps**
```gherkin
Feature: my feature name
Scenario: user [verb for user action]
Given [describe expected initial app state]
When user [verb for user action]
Then [describe expected outcome]
```
## **Screenshots/Recordings**
<!-- If applicable, add screenshots and/or recordings to visualize the
before and after of your change. -->
### **Before**
<!-- [screenshots/recordings] -->
### **After**
<!-- [screenshots/recordings] -->
## **Pre-merge author checklist**
- [ ] I've followed [MetaMask Contributor
Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile
Coding
Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md).
- [ ] I've completed the PR template to the best of my ability
- [ ] I've included tests if applicable
- [ ] I've documented my code using [JSDoc](https://jsdoc.app/) format
if applicable
- [ ] I've applied the right labels on the PR (see [labeling
guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)).
Not required for external contributors.
## **Pre-merge reviewer checklist**
- [ ] I've manually tested the PR (e.g. pull and build branch, run the
app, test code being changed).
- [ ] I confirm that this PR addresses all acceptance criteria described
in the ticket it closes and includes the necessary testing evidence such
as recordings and or screenshots.
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> **Low Risk**
> Low risk text-only change: updates i18n keys used for the Market
Insights disclaimers and removes unused English strings, with no logic
or data-flow changes.
>
> **Overview**
> Updates Market Insights UI to use a single
`market_insights.footer_disclaimer` string for both the entry card and
full view footer, replacing the previous
`disclaimer`/`fixed_footer_disclaimer` keys.
>
> Cleans up `en.json` by removing the old keys and keeping the updated
disclaimer copy in one place.
>
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
f17ed96. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
…event (#26785) ## **Description** When tapping the `>` arrow on the Perps homepage section, the `Perp Screen Viewed` analytics event was firing with `source: main_action_button` (the fallback default) instead of the correct entry point. This fix passes `source: home_screen` explicitly when navigating from the homepage section title and "View more" card. Changes: - Added `HOME_SCREEN: 'home_screen'` to `PERPS_EVENT_VALUE.SOURCE` constants - Updated `handleViewAllPerps` in `PerpsSection` to pass the new source param on navigation - Updated related tests to assert the correct source value ## **Changelog** CHANGELOG entry: null ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/TMCU-501 ## **Manual testing steps** ```gherkin Feature: Perps homepage section navigation analytics Scenario: user taps the > arrow on the Perps section Given the user is on the homepage with the Perps section visible When user taps the ">" arrow next to "Perpetuals" Then the "Perp Screen Viewed" event fires with source = "home_screen" Scenario: user taps "View more" in the trending carousel Given the user is on the homepage with no open positions or orders When user taps the "View more" card in the Perps trending carousel Then the "Perp Screen Viewed" event fires with source = "home_screen" ``` ## **Screenshots/Recordings** `~` ### **Before** `~` ### **After** `~` ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. ## **Pre-merge reviewer checklist** - [x] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [x] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Only updates test case descriptions (no runtime logic changes), so behavior and production risk are minimal. > > **Overview** > Updates `PerpsSection.test.tsx` to clarify in test names which `source` param is expected when navigating to Perps home from the homepage section title and the "View more" card. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit fcf9495. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY -->
…ssion (#26954) ## **Description** Polymarket's CLOB infrastructure is intermittently returning 400 errors with "not enough balance / allowance" when placing orders at high request rates. As a temporary workaround communicated by the Polymarket team, we now call `GET /balance-allowance/update` before each order to refresh the balance/allowance state on their end. ### Changes: - **`utils.ts`**: Add `refreshBalanceAllowance()` utility that calls the CLOB balance-allowance/update endpoint with L2 HMAC auth headers - BUY orders → `asset_type=COLLATERAL` (USDC) - SELL orders → `asset_type=CONDITIONAL` with the order's `token_id` - **`PolymarketProvider.ts`**: Call `refreshBalanceAllowance()` in `placeOrder()` right before `submitClobOrder()`, wrapped in try/catch so failures don't block order submission - **`utils.test.ts`**: 5 new tests covering BUY/SELL paths, auth headers, error resilience, and custom signature types - **`PolymarketProvider.test.ts`**: 4 new integration tests verifying call ordering, parameter passing for both sides, and graceful degradation on refresh failure > **Note**: This is a temporary workaround. TODO comments are in place for removal once Polymarket resolves the underlying infrastructure issue. ## **Changelog** CHANGELOG entry: null ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/PRED-726 ## **Manual testing steps** ```gherkin Feature: Polymarket order placement with balance/allowance refresh Scenario: user places a BUY order on a prediction market Given the user has USDC deposited in their Polymarket proxy wallet When user places a BUY order on any market Then the balance/allowance refresh call fires before the order submission And the order completes successfully Scenario: user places a SELL order on a prediction market Given the user holds outcome tokens for a market When user places a SELL order Then the balance/allowance refresh call fires with the token_id before the order And the order completes successfully Scenario: balance/allowance refresh endpoint is down Given the refresh endpoint returns an error When user places any order Then the order submission still proceeds normally ``` ## **Screenshots/Recordings** N/A — no UI changes ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. ## **Pre-merge reviewer checklist** - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Adds a new preflight network call in the order placement path; while failures are best-effort and don’t block orders, it changes timing/behavior in a core trading flow and could affect reliability or rate limits. > > **Overview** > Adds a temporary workaround for intermittent Polymarket CLOB `not enough balance / allowance` errors by introducing `refreshBalanceAllowance()` (calls `GET /balance-allowance/update` with L2 HMAC headers) and invoking it in `PolymarketProvider.placeOrder()` immediately before `submitClobOrder()`. > > The refresh is **best-effort** (wrapped in `try/catch` with logging) and varies request params by side: **BUY** refreshes `asset_type=COLLATERAL`, **SELL** refreshes `asset_type=CONDITIONAL` with `token_id`. Updates unit/integration tests to cover parameter selection, call ordering, header usage, and non-blocking behavior on refresh failure. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 8a46817. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY -->
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
9 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )