[pull] main from MetaMask:main#796
Merged
Merged
Conversation
…' on 'EventTa… (#30701) …rget': parameter 1 is not of type 'Event' (#30612) ## **Description** Fix `TypeError: Failed to execute 'dispatchEvent' on 'EventTarget': parameter 1 is not of type 'Event'` crash caused by the `CloseEvent` polyfill in `shim.js` using `event-target-shim`'s `Event` class instead of React Native's own `Event` class. When `@nktkas/rews` (Hyperliquid SDK WebSocket transport) dispatches a `CloseEvent` on the native WebSocket, RN's `dispatchEvent` validates `event instanceof RNEvent` — which failed because `event-target-shim` provides a different `Event` class. Replaced `event-target-shim` globals with React Native's own `Event`, `EventTarget`, `CloseEvent`, and `MessageEvent` classes so all `instanceof` checks pass consistently. ## **Changelog** CHANGELOG entry: Fixed a crash caused by CloseEvent dispatch on WebSocket failing instanceof validation ## **Related issues** Fixes: [TAT-3223](https://consensyssoftware.atlassian.net/browse/TAT-3223) ## **Manual testing steps** ```gherkin Feature: CloseEvent dispatch on native WebSocket Scenario: CloseEvent is dispatched on native WebSocket without error Given the app is running with Hyperliquid SDK active When a WebSocket connection is closed while in CONNECTING state Then no TypeError is thrown And the CloseEvent is dispatched successfully ``` ## **Screenshots/Recordings** State-only fix: no visual evidence needed. Both ACs proven via CDP eval (CloseEvent dispatch success) and lint:tsc (no TS errors). ## **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. ## **Validation Recipe** <details> <summary>recipe.json</summary> ```json { "pr": "TAT-3223", "title": "CloseEvent dispatchEvent on native WebSocket must not throw TypeError", "jira": "TAT-3223", "acceptance_criteria": [ "CloseEvent dispatched on native WebSocket must not throw TypeError", "No new TypeScript errors introduced by the fix" ], "validate": { "static": ["yarn lint:tsc"], "workflow": { "pre_conditions": ["wallet.unlocked"], "entry": "ac1-eval-closeevent-dispatch", "nodes": { "ac1-eval-closeevent-dispatch": { "action": "eval_sync", "expression": "(function() { try { var ws = new WebSocket('wss://echo.websocket.org'); var ce = new CloseEvent('close', {code: 1006, reason: '', wasClean: false}); ws.dispatchEvent(ce); ws.close(); return JSON.stringify({success: true, error: null}); } catch(e) { return JSON.stringify({success: false, error: e.message}); } })()", "assert": { "operator": "eq", "field": "success", "value": true }, "next": "ac1-eval-closeevent-props" }, "ac1-eval-closeevent-props": { "action": "eval_sync", "expression": "(function() { var ce = new CloseEvent('close', {code: 1006, reason: 'test', wasClean: true}); return JSON.stringify({type: ce.type, code: ce.code, reason: ce.reason, wasClean: ce.wasClean}); })()", "assert": { "all": [ { "operator": "eq", "field": "code", "value": 1006 }, { "operator": "eq", "field": "reason", "value": "test" }, { "operator": "eq", "field": "wasClean", "value": true } ] }, "next": "ac1-eval-messageevent-dispatch" }, "ac1-eval-messageevent-dispatch": { "action": "eval_sync", "expression": "(function() { try { var ws = new WebSocket('wss://echo.websocket.org'); var me = new MessageEvent('message', {data: 'hello'}); ws.dispatchEvent(me); ws.close(); return JSON.stringify({success: true, error: null}); } catch(e) { return JSON.stringify({success: false, error: e.message}); } })()", "assert": { "operator": "eq", "field": "success", "value": true }, "next": "setup-done" }, "setup-done": { "action": "end", "status": "pass" } } } } } ``` </details> ## **Recipe Workflow** <details> <summary>workflow.mmd</summary> ```mermaid graph TD ac1-eval-closeevent-dispatch["ac1-eval-closeevent-dispatch<br/>eval_sync: CloseEvent dispatch on native WS"] ac1-eval-closeevent-props["ac1-eval-closeevent-props<br/>eval_sync: Verify CloseEvent properties"] ac1-eval-messageevent-dispatch["ac1-eval-messageevent-dispatch<br/>eval_sync: MessageEvent dispatch on native WS"] setup-done["setup-done<br/>end: pass"] ac1-eval-closeevent-dispatch --> ac1-eval-closeevent-props ac1-eval-closeevent-props --> ac1-eval-messageevent-dispatch ac1-eval-messageevent-dispatch --> setup-done ``` </details> [TAT-3223]: https://consensyssoftware.atlassian.net/browse/TAT-3223?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Touches app bootstrap polyfills used by Hyperliquid WebSockets; low blast radius but wrong globals could break perps connectivity at runtime. > > **Overview** > Fixes a **Hyperliquid / perps WebSocket crash** where `dispatchEvent` rejected `CloseEvent` because polyfilled events did not pass React Native’s `instanceof Event` check. > > **`shim.js`** stops using **`event-target-shim`** and hand-rolled `CloseEvent` / `MessageEvent` constructors. When globals are missing, it assigns React Native’s own **`Event`**, **`EventTarget`**, **`CloseEvent`**, and **`MessageEvent`** from RN private web API modules so events dispatched by `@nktkas/rews` match what RN’s WebSocket `EventTarget` expects. > > **`event-target-shim`** is removed from **`package.json`** / lockfile. **`shim.test.js`** adds unit coverage for RN `CloseEvent` and `MessageEvent` properties and inheritance. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 5d5cb89. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> <!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until this PR meets the canonical Definition of Ready For Review in `docs/readme/ready-for-review.md`. In short: the template must be materially complete (not just section titles present), all status checks must be currently passing, and the only expected follow-up commits must be reviewer-driven. --> ## **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: ## **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** <!-- Every checklist item must be consciously assessed before marking this PR as "Ready for review". A checked box means you deliberately considered that responsibility, not that you literally performed every action listed. Unchecked boxes are ambiguous: they are not an implicit "N/A" and they are not a silent "skip". See `docs/readme/ready-for-review.md` for the full checklist semantics. --> - [ ] 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. #### Performance checks (if applicable) - [ ] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [ ] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [ ] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **Pre-merge reviewer checklist** <!-- Reviewer checklist items follow the same semantics as the author checklist: an unchecked box is ambiguous, a checked box means the reviewer consciously assessed that responsibility. See `docs/readme/ready-for-review.md`. --> - [ ] 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. [TAT-3223]: https://consensyssoftware.atlassian.net/browse/TAT-3223?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ [TAT-3223]: https://consensyssoftware.atlassian.net/browse/TAT-3223?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ Co-authored-by: abretonc7s <107169956+abretonc7s@users.noreply.github.com>
This reverts commit a3715bb.
<!--
Please submit this PR as a draft initially.
Do not mark it as "Ready for review" until this PR meets the canonical
Definition of Ready For Review in `docs/readme/ready-for-review.md`.
In short: the template must be materially complete (not just section
titles
present), all status checks must be currently passing, and the only
expected
follow-up commits must be reviewer-driven.
-->
## **Description**
Add the `[7.78.1]` section to `CHANGELOG.md` for the `v7.78.1` OTA
hotfix.
## **Changelog**
CHANGELOG entry: null
## **Related issues**
Fixes:
<!--
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:
## **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**
<!--
Every checklist item must be consciously assessed before marking this PR
as
"Ready for review". A checked box means you deliberately considered that
responsibility, not that you literally performed every action listed.
Unchecked boxes are ambiguous: they are not an implicit "N/A" and they
are not
a silent "skip". See `docs/readme/ready-for-review.md` for the full
checklist
semantics.
-->
- [ ] 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.
#### Performance checks (if applicable)
- [ ] I've tested on Android
- Ideally on a mid-range device; emulator is acceptable
- [ ] I've tested with a power user scenario
- Use these [power-user
SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93)
to import wallets with many accounts and tokens
- [ ] I've instrumented key operations with Sentry traces for production
performance metrics
- See [`trace()`](/app/util/trace.ts) for usage and
[`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274)
for an example
For performance guidelines and tooling, see the [Performance
Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers).
## **Pre-merge reviewer checklist**
<!--
Reviewer checklist items follow the same semantics as the author
checklist: an
unchecked box is ambiguous, a checked box means the reviewer consciously
assessed that responsibility. See `docs/readme/ready-for-review.md`.
-->
- [ ] 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.
---------
Co-authored-by: metamaskbot <metamaskbot@users.noreply.github.com>
OTA hotfix: branch `release/7.78.1-ota`. - Native semver and build version are **not** bumped. - `OTA_VERSION` in `app/constants/ota.ts` is `v7.78.1`. - CHANGELOG.md header and production git tag both use bare `7.78.1` / `v7.78.1`; the `-ota` suffix is branch-only.
<!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until this PR meets the canonical Definition of Ready For Review in `docs/readme/ready-for-review.md`. In short: the template must be materially complete (not just section titles present), all status checks must be currently passing, and the only expected follow-up commits must be reviewer-driven. --> ## **Description** Fix audit issue: GHSA-35jp-ww65-95wh <!-- 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: ## **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** <!-- Every checklist item must be consciously assessed before marking this PR as "Ready for review". A checked box means you deliberately considered that responsibility, not that you literally performed every action listed. Unchecked boxes are ambiguous: they are not an implicit "N/A" and they are not a silent "skip". See `docs/readme/ready-for-review.md` for the full checklist semantics. --> - [ ] 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. #### Performance checks (if applicable) - [ ] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [ ] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [ ] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **Pre-merge reviewer checklist** <!-- Reviewer checklist items follow the same semantics as the author checklist: an unchecked box is ambiguous, a checked box means the reviewer consciously assessed that responsibility. See `docs/readme/ready-for-review.md`. --> - [ ] 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** > Dependency-only security patch with no app code changes; standard patch-level HTTP client upgrade. > > **Overview** > Bumps **axios** from `^1.15.x` to **`^1.16.0`** in `package.json` (direct dependency and Yarn **resolutions**) and refreshes **`yarn.lock`** so the tree resolves to **axios 1.16.1**, addressing advisory [GHSA-35jp-ww65-95wh](GHSA-35jp-ww65-95wh). > > The lockfile also picks up **follow-redirects** `1.16.0` and axios’s updated transitive deps (e.g. **https-proxy-agent**). No application source changes. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit e4f36bb. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
This PR syncs the stable branch to main for version 7.78.0. *Synchronization Process:* - Fetches the latest changes from the remote repository - Resets the branch to match the stable branch - Attempts to merge changes from main into the branch - Handles merge conflicts if they occur *File Preservation:* Preserves specific files from the stable branch: - CHANGELOG.md - bitrise.yml - android/app/build.gradle - ios/MetaMask.xcodeproj/project.pbxproj - package.json Indicates the next version candidate of main to 7.78.0
<!--
Please submit this PR as a draft initially.
Do not mark it as "Ready for review" until this PR meets the canonical
Definition of Ready For Review in `docs/readme/ready-for-review.md`.
In short: the template must be materially complete (not just section
titles
present), all status checks must be currently passing, and the only
expected
follow-up commits must be reviewer-driven.
-->
## **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?
-->
fix release automation by restoring bitrise.yml. Needed for version bump
workflows.
## **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**
<!--
Every checklist item must be consciously assessed before marking this PR
as
"Ready for review". A checked box means you deliberately considered that
responsibility, not that you literally performed every action listed.
Unchecked boxes are ambiguous: they are not an implicit "N/A" and they
are not
a silent "skip". See `docs/readme/ready-for-review.md` for the full
checklist
semantics.
-->
- [ ] 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.
#### Performance checks (if applicable)
- [ ] I've tested on Android
- Ideally on a mid-range device; emulator is acceptable
- [ ] I've tested with a power user scenario
- Use these [power-user
SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93)
to import wallets with many accounts and tokens
- [ ] I've instrumented key operations with Sentry traces for production
performance metrics
- See [`trace()`](/app/util/trace.ts) for usage and
[`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274)
for an example
For performance guidelines and tooling, see the [Performance
Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers).
## **Pre-merge reviewer checklist**
<!--
Reviewer checklist items follow the same semantics as the author
checklist: an
unchecked box is ambiguous, a checked box means the reviewer consciously
assessed that responsibility. See `docs/readme/ready-for-review.md`.
-->
- [ ] 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.
) # feat(predict): add predictHomeRedesign feature flag and selector ## **Description** Part of the **PRED-834 — IA & Navigation Overhaul** epic. This PR adds a standalone, version-gated remote feature flag `predictHomeRedesign` so the redesigned Predict homepage/feed IA can be rolled out independently from the PRED-835 portfolio work. **Reason for the change:** PRED-834 (homepage/feed IA) and PRED-835 (portfolio module) need separate rollout controls. Reusing the existing `predictPortfolio` flag would couple the two efforts; a dedicated flag keeps them independently gated. **What it does:** - Adds a new Predict feature flag shaped as `{ enabled: boolean; minimumVersion: string }` (a standard `VersionGatedFeatureFlag`), defaulting to disabled. - Resolves it through the existing Predict feature flag pipeline and exposes a selector, mirroring the existing `predictPortfolio` flag one-for-one. - No routing or UI changes: nothing consumes the selector yet. The redesigned homepage shell and the market-list route mount land in the follow-up PRED-834 ticket. As a result, existing Predict UI is unchanged while the flag is disabled (the default). **Scope / constraints:** - Does **not** reuse the PRED-835 `predictPortfolio` flag; that module remains separately gated by `predictPortfolio.enabled`. - No `DEFAULT_*` constant added (consistent with `predictPortfolio`); the `{ enabled: false, minimumVersion: '' }` default is handled by the resolver's fallback-to-`false` plus version gating. ### Changes - `app/components/UI/Predict/types/flags.ts` — added `predictHomeRedesignEnabled: boolean` to the `PredictFeatureFlags` interface. - `app/components/UI/Predict/utils/resolvePredictFeatureFlags.ts` — resolves `predictHomeRedesignEnabled` via `resolveVersionGatedBooleanFlag(flags.predictHomeRedesign)` and returns it. - `app/components/UI/Predict/selectors/featureFlags/index.ts` — added `selectPredictHomeRedesignEnabledFlag`. - `app/components/UI/Predict/utils/resolvePredictFeatureFlags.test.ts` — added default expectation + `predictHomeRedesignEnabled` resolution tests. - `app/components/UI/Predict/selectors/featureFlags/index.test.ts` — added `selectPredictHomeRedesignEnabledFlag` selector tests. ## **Changelog** CHANGELOG entry: null <!-- Not end-user-facing: flag plumbing only, no observable behavior until the follow-up shell ticket wires a consumer. --> ## **Related issues** Refs: PRED-834 ## **Manual testing steps** ```gherkin Feature: predictHomeRedesign feature flag Scenario: Flag disabled by default leaves existing Predict UI unchanged Given the predictHomeRedesign remote flag is absent or disabled When the user opens the Predict tab Then the existing Predict feed renders exactly as before Scenario: Selector returns false by default Given no predictHomeRedesign remote config is present When selectPredictHomeRedesignEnabledFlag is evaluated Then it returns false Scenario: Malformed remote config falls back to disabled Given the predictHomeRedesign remote flag has an invalid shape When selectPredictHomeRedesignEnabledFlag is evaluated Then it returns false Scenario: Minimum-version gating Given the predictHomeRedesign flag is enabled with a minimumVersion above the app version When selectPredictHomeRedesignEnabledFlag is evaluated Then it returns false ``` Automated coverage (run locally): ```bash yarn jest \ app/components/UI/Predict/utils/resolvePredictFeatureFlags.test.ts \ app/components/UI/Predict/selectors/featureFlags/index.test.ts ``` Result: 2 suites passed, 124 tests passed. ## **Screenshots/Recordings** N/A — no user-facing UI changes (flag has no consumer yet). ### **Before** N/A ### **After** N/A ## **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. #### Performance checks (if applicable) - [ ] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [ ] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [ ] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example <!-- Performance checks N/A: no runtime code path is executed by this change (no consumer yet). --> ## **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** > Flag plumbing only with no runtime UI consumer; axios is a minor dependency patch bump with existing test coverage for flag behavior. > > **Overview** > Adds a **standalone, version-gated** remote flag `predictHomeRedesign` so the Predict homepage/feed IA (PRED-834) can roll out **independently** of `predictPortfolio` (PRED-835). > > The flag is wired through the existing Predict pipeline: `predictHomeRedesignEnabled` on `PredictFeatureFlags`, resolution via `resolveVersionGatedBooleanFlag(flags.predictHomeRedesign)` (defaults to **false**), and `selectPredictHomeRedesignEnabledFlag`. Tests mirror `predictPortfolio` (missing, disabled, malformed, version gate, progressive rollout unwrap). **No UI or routing** consumes the selector yet. > > Also bumps **axios** from `^1.15.x` to **`^1.16.0`** in `package.json` and `yarn.lock`. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit c514bf2. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
<!--
Please submit this PR as a draft initially.
Do not mark it as "Ready for review" until this PR meets the canonical
Definition of Ready For Review in `docs/readme/ready-for-review.md`.
In short: the template must be materially complete (not just section
titles
present), all status checks must be currently passing, and the only
expected
follow-up commits must be reviewer-driven.
-->
## **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?
-->
Fixes an issue where the marketing_consent notification pre-prompt could
be re-triggered during the same app session after the user turned
marketing consent off in Settings.
The pre-prompt is intended to behave as a startup flow. This change
latches the marketing consent value used for startup prompt resolution,
so once startup eligibility has resolved, later Redux updates from user
actions do not cause the prompt to appear unexpectedly.
Social-login marketing consent backfill is still respected as part of
startup resolution. If backfill is pending, the prompt waits for it to
clear, then decides once using the resolved consent value.
Risk
Low risk.
This change is scoped to usePushPrePromptVariant, which only decides
which notification pre-prompt variant to show. It does not change
notification registration, OS permission requests, Settings behavior,
analytics opt-in/out behavior, or persisted storage keys.
The change preserves existing behavior for the main paths:
Users without OS push permission still resolve to the push permission
prompt first.
Users who already saw the pre-prompt remain suppressed by
PUSH_PRE_PROMPT_SHOWN.
Users with marketing consent enabled do not see the marketing consent
prompt.
Users with marketing consent disabled at startup can still see the
one-time startup prompt if otherwise eligible.
Social-login users still wait for marketing consent backfill before the
marketing prompt decision is made.
The risk is low because the fix narrows when the marketing consent
prompt can appear rather than expanding eligibility. The only behavior
removed is the unintended mid-session re-trigger after Settings opt-out.
## **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: Fixed an issue where the marketing consent notification
pre-prompt could reappear after turning marketing consent off in
Settings.
## **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**
<!--
Every checklist item must be consciously assessed before marking this PR
as
"Ready for review". A checked box means you deliberately considered that
responsibility, not that you literally performed every action listed.
Unchecked boxes are ambiguous: they are not an implicit "N/A" and they
are not
a silent "skip". See `docs/readme/ready-for-review.md` for the full
checklist
semantics.
-->
- [ ] 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.
#### Performance checks (if applicable)
- [ ] I've tested on Android
- Ideally on a mid-range device; emulator is acceptable
- [ ] I've tested with a power user scenario
- Use these [power-user
SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93)
to import wallets with many accounts and tokens
- [ ] I've instrumented key operations with Sentry traces for production
performance metrics
- See [`trace()`](/app/util/trace.ts) for usage and
[`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274)
for an example
For performance guidelines and tooling, see the [Performance
Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers).
## **Pre-merge reviewer checklist**
<!--
Reviewer checklist items follow the same semantics as the author
checklist: an
unchecked box is ambiguous, a checked box means the reviewer consciously
assessed that responsibility. See `docs/readme/ready-for-review.md`.
-->
- [ ] 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.
…urface shim (#30708) ## **Description** Part of the pure-black dark mode rollout. The MMDS package's `BottomSheet` paints `bg-default` internally, which collapses to `#000` against the pure-black screen background when `MM_PURE_BLACK_PREVIEW=true`. Until the package ships its own pure-black-aware surface, every consumer of the DS package `BottomSheet` now passes `twClassName={surfaceClass}` (sourced from `useElevatedSurface()`). The hook returns `bg-default` when the flag is off (no-op for current users) and `bg-section` under pure-black dark mode. 50 files updated. No behavioral change with the flag off. Cleanup once the package ships is mechanical: `grep -r "useElevatedSurface\|surfaceClass" app/` → remove. ## **Changelog** CHANGELOG entry: null ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/TMCU-798 ## **Manual testing steps** ```gherkin Feature: MMDS BottomSheet surfaces stay visible under MM_PURE_BLACK_PREVIEW Scenario: A bottom sheet is opened under pure-black dark mode Given MM_PURE_BLACK_PREVIEW=true and the app is in dark mode When the user triggers any flow that opens an MMDS BottomSheet (e.g. Onboarding sign-in sheet, Address selector, Bridge price impact, Money transfer, Rewards opt-in, Perps tooltips, Ramp modals) Then the sheet panel renders an elevated surface (background.section) against the dimmed scrim, not a pure-black panel And dismissing/reopening the sheet preserves the elevation Scenario: Flag off — appearance unchanged Given MM_PURE_BLACK_PREVIEW is unset or false When the user opens any of the same sheets Then they render exactly as they do on main ``` ## **Screenshots/Recordings** ### Example Instance | Before | After | |--------|-------| |  |  | ### **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. #### Performance checks (if applicable) - [ ] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [ ] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [ ] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **Pre-merge reviewer checklist** <!-- Reviewer checklist items follow the same semantics as the author checklist: an unchecked box is ambiguous, a checked box means the reviewer consciously assessed that responsibility. See `docs/readme/ready-for-review.md`. --> - [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** > Flag-gated UI background classes only; no auth, transactions, or data-path changes, and default builds remain visually unchanged. > > **Overview** > Adds a **pure-black preview stopgap** so MMDS `BottomSheet` panels stay visually elevated when `MM_PURE_BLACK_PREVIEW=true` in dark mode (where default sheet background would match a `#000` screen). > > **`themeUtils`** documents `useElevatedSurface` / `getElevatedSurfaceColor`: flag off → `bg-default` (unchanged); flag on + dark → `bg-alternative`; light mode unchanged. > > **~50 call sites** import `useElevatedSurface`, set `const surfaceClass = useElevatedSurface()`, and pass **`twClassName={surfaceClass}`** on design-system `BottomSheet` (Bridge batch-sell and alerts, Money sheets, Ramp modals/checkout, Perps/Predict/Rewards, onboarding, address/SRP selectors, confirmations pay-with and send alerts, NFT grid actions, etc.). Some files only reorder imports alongside this wiring. > > No product logic changes; behavior with the flag off should match main. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 2ac348c. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
## **Description**
Remove OTA publishing and release-tag creation from the automated/Runway
CI flows. OTA updates are now published and tagged manually in Runway,
so CI only needs to detect OTA bumps (to skip native builds) and
otherwise build.
**Changes**
**auto-rc-ota-build-core.yml (Auto RC build/OTA core)**
- Removed the trigger-ota job (no longer pushes EAS OTA updates via
push-eas-update.yml).
- Removed the validate-ota-pr job (only existed to guard the OTA push).
- Removed the create-ota-production-tag job and the
create_production_ota_tag + ota_channel inputs.
- Kept OTA detection: resolve-context still runs and trigger-build
remains gated on ota_bump != 'true', so OTA-only branches skip the
native build instead of building.
- Tightened permissions from contents: write + actions: write +
pull-requests: read + id-token: write down to contents: read +
pull-requests: read + id-token: write.
**runway-ota-production.yml (Runway OTA Production)**
- Removed the create-ota-production-tag job — the v<OTA_VERSION> tag is
now created manually in Runway.
- Tightened permissions contents: write → contents: read (write was only
needed to push the tag).
- Updated header comment + source_branch input description.
**runway-create-ota-production-tag.yml**
Deleted — it was the reusable tag-creation workflow and is no longer
referenced by any caller after the changes above.
## **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**
<!--
Every checklist item must be consciously assessed before marking this PR
as
"Ready for review". A checked box means you deliberately considered that
responsibility, not that you literally performed every action listed.
Unchecked boxes are ambiguous: they are not an implicit "N/A" and they
are not
a silent "skip". See `docs/readme/ready-for-review.md` for the full
checklist
semantics.
-->
- [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.
#### Performance checks (if applicable)
- [ ] I've tested on Android
- Ideally on a mid-range device; emulator is acceptable
- [ ] I've tested with a power user scenario
- Use these [power-user
SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93)
to import wallets with many accounts and tokens
- [ ] I've instrumented key operations with Sentry traces for production
performance metrics
- See [`trace()`](/app/util/trace.ts) for usage and
[`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274)
for an example
For performance guidelines and tooling, see the [Performance
Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers).
## **Pre-merge reviewer checklist**
<!--
Reviewer checklist items follow the same semantics as the author
checklist: an
unchecked box is ambiguous, a checked box means the reviewer consciously
assessed that responsibility. See `docs/readme/ready-for-review.md`.
-->
- [ ] 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 release automation boundaries—OTA-only RC pushes will skip
native builds without CI publishing OTA, so Runway/manual steps must
stay in sync or releases can stall.
>
> **Overview**
> CI no longer publishes EAS OTA updates or creates `v<OTA_VERSION>`
release tags; those steps move to manual Runway handling.
>
> **`auto-rc-ota-build-core.yml`** drops `trigger-ota`,
`validate-ota-pr`, and `create-ota-production-tag`, plus inputs
`ota_channel` and `create_production_ota_tag`. It still runs
`resolve-context` and only runs native **`build.yml`** (and TestFlight
on iOS) when `ota_bump != 'true'`, so OTA-only commits skip binaries.
Permissions are reduced to `contents: read` (no tag push or workflow
dispatch for OTA).
>
> **`runway-ota-production.yml`** still pushes production OTA via
`push-eas-update.yml` but no longer creates the production release tag.
**`runway-create-ota-production-tag.yml`** is deleted.
>
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
0a209ff. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
Co-authored-by: João Loureiro <175489935+joaoloureirop@users.noreply.github.com>
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.
7 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 : )