## **Description** Split from #26651 to reduce CODEOWNERS fanout. Batch: confirmations Source branch: \`origin/remove-static-hex-from-tests\` When \`@metamask/design-tokens\` upgrades change color values, tests that hardcode hex literals (e.g. \`'#ffffff'\`) break because the component renders the new token value while the test still asserts the old one — even though nothing is actually wrong. This PR fixes that brittleness across the confirmations scope. **Two strategies are applied:** 1. **Replace hardcoded hex with token references** — test mocks and assertions use \`mockTheme.colors.*\` (or \`brandColor.*\` for production code) so the test always agrees with whatever the current token value is. Package upgrades no longer cause spurious failures. 2. **Add targeted \`eslint-disable\` comments** — strings like \`'#12345'\` or \`'#456'\` are NFT token IDs that happen to look like hex colors. The \`color-no-hex\` rule can't distinguish them from CSS colors, so suppress comments are added inline to keep the rule enforced everywhere else without false positives. Together these changes make the \`@metamask/design-tokens/color-no-hex\` lint rule enforceable across this scope, so future hex literals won't accidentally creep in. ## **Changelog** CHANGELOG entry: null ## **Related issues** Fixes: ## **Manual testing steps** \`\`\`gherkin Feature: color-no-hex lint compliance (confirmations batch) Scenario: user runs lint Given the confirmations test files have been updated When user runs the lint checks Then no color-no-hex violations are reported \`\`\` ## **Screenshots/Recordings**  ### **Before**  ### **After**  ## **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.

Uh oh!

ENS / IPFS resolution is broken #456

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions