feat(home): refresh home screen chrome

[CassioMG]

Part of the Home refresh project. This is the Home screen's chrome — header, action row, tab row, and the new floating "+ Add token/collectible" buttons.

What changed

Per Figma frames 9567-17044 (Home) and 9673-19461 (Add Collectible):

• History moves into the top icon row, between the options … button and the network globe. The order is now options → history → network.
• The action row becomes three equal columns — Add / Send / Swap — filling the width. History left the row to make space.
• The tab row is just Tokens | Collectibles, active tab purple with an underline. The Sliders01 manage button and its whole dropdown are deleted.
• New floating "Add token" / "Add collectible" pill replaces that dropdown, labelled and routed by the active tab.
• Hidden collectibles moved from the deleted dropdown to a purple "Show hidden" button on the Add Collectible screen, with new helper text and an X header icon.

home-chrome-720p.mov

Analytics

Unchanged. history.full_history_opened moved position but kept its event name and source: "account_header" verbatim — still accurate, since both the old and new positions are in the header.

Note "Manage tokens" is not orphaned by deleting the tab dropdown: the … menu already routes to ROUTES.manageAssets.

Also removed a genuinely dead isIncludingIcons prop from TabButtons — its JSDoc claimed it was "used in Send flow", but a grep across src and e2e-tests finds no consumer.

Verification

• yarn test:ci — 1520/1571 tests, identical to baseline
• yarn build:extension — clean
• e2e: accountHistory (11 passed, unedited), addCollectible, hideCollectible, loadAccount, addAsset — all green
• Both add-collectible-page snapshots regenerated and visually inspected

🤖 Generated with Claude Code

[github-actions]

PR Preview build is ready: https://github.com/stellar/freighter/releases/tag/untagged-ee46b743957bfc5b8627 (SDF collaborators only — install instructions in the release description)

[Copilot]

Pull request overview

Refreshes the Home screen chrome and relocates hidden-collectible management.

Changes:

• Reworks header actions, history placement, and tabs.
• Adds contextual floating token/collectible actions.
• Moves hidden collectibles to the Add Collectible screen.

Reviewed changes

Copilot reviewed 18 out of 20 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
extension/src/popup/views/AddCollectibles/styles.scss	Styles helper text and hidden-items action.
extension/src/popup/views/AddCollectibles/index.tsx	Adds hidden-collectibles access and revised header.
extension/src/popup/views/Account/styles.scss	Reserves space for the floating action.
extension/src/popup/views/Account/index.tsx	Renders the contextual add button.
extension/src/popup/locales/pt/translation.json	Adds Portuguese translations.
extension/src/popup/locales/en/translation.json	Adds English translation keys.
extension/src/popup/components/account/NotFundedMessage/styles.scss	Updates empty-state spacing and typography.
extension/src/popup/components/account/NotFundedMessage/index.tsx	Enlarges the funding action.
extension/src/popup/components/account/MobileAppBanner/styles.scss	Aligns the banner with the refreshed layout.
extension/src/popup/components/account/FloatingAddButton/styles.scss	Styles the floating add pill.
extension/src/popup/components/account/FloatingAddButton/index.tsx	Routes contextual token or collectible actions.
extension/src/popup/components/account/AccountTabs/styles.scss	Implements the simplified tab appearance.
extension/src/popup/components/account/AccountTabs/index.tsx	Removes the asset-management dropdown.
extension/src/popup/components/account/AccountHeader/styles.scss	Refreshes header, balance, and action-row styling.
extension/src/popup/components/account/AccountHeader/index.tsx	Moves history and reduces actions to three columns.
extension/src/popup/components/account/AccountCollectibles/styles.scss	Adjusts collectible empty-state spacing.
extension/e2e-tests/hideCollectible.test.ts	Updates hidden-collectible navigation tests.
extension/e2e-tests/addCollectible.test.ts	Updates collectible-add navigation coverage.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[CassioMG]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

🤖 Generated with Claude Code

[piyalbasu]

Floating add pill can cover the row a keyboard user just focused

Accessibility — WCAG 2.2 AA (2.4.11 Focus Not Obscured), low-to-moderate severity — not a merge blocker.

TL;DR: The new floating "Add token / Add collectible" pill sits pinned to the bottom of the window while the list scrolls behind it. The extra space added at the bottom of the list only guarantees the last row clears the pill — rows in the middle of the list still pass underneath it as you scroll. So a keyboard user tabbing down the token list can end up with the highlighted row hidden behind the pill, and a mouse user can have a click land on the pill instead of the row beneath it.

Steps to reproduce:

1. Open Home on a funded account with enough tokens to scroll (roughly 8+).
2. Click the first token row, then press Tab repeatedly to walk down the list.
3. Watch the focus ring as it approaches the bottom of the window — on the rows where the browser scrolls just enough to bring the next row into view, the focus ring lands behind the pill instead of above it.
4. Alternatively, scroll so a mid-list row sits under the pill and try to click that row.

---

Detailed explanation (for agents)

Root cause: the pill is taken out of flow and pinned to the viewport:

freighter/extension/src/popup/components/account/FloatingAddButton/styles.scss

Lines 3 to 14 in 0ace8b0

	.FloatingAddButton {
	// Fixed, not absolute: on Home the layout has no inner scroll container —
	// `.View` grows with the token list and the document itself scrolls. Any
	// absolutely-positioned anchor therefore rides along with the content.
	// Fixed pins the pill to the viewport, which is what "floating" means here.
	// Safe because no ancestor sets transform/filter/backdrop-filter, which
	// would otherwise turn into its containing block.
	position: fixed;
	bottom: pxToRem(24px);
	left: 50%;
	transform: translateX(-50%);
	z-index: var(--z-index--banner);

The mitigation is bottom padding on the pane:

freighter/extension/src/popup/views/Account/styles.scss

Lines 63 to 70 in 0ace8b0

	&__pane {
	padding: 0 var(--account-view-padding-side);
	// Reserve room below the last row so the floating add pill (an
	// absolutely-positioned overlay pinned near the bottom of the view)
	// never sits on top of real list content and swallows its clicks.
	padding-bottom: pxToRem(88px);
	height: auto;
	overflow: auto;

padding-bottom extends the scrollable content past the end of the list, which correctly stops the pill from resting on the final row at max scroll. It does nothing for intermediate scroll positions: the pill is fixed to the viewport, so at any scroll offset other than the very bottom there is real list content occupying the 24px–60px band the pill covers.

The keyboard case is the one that trips a WCAG check. When focus moves to an element outside the visible area, the browser performs a minimal scroll to bring it into view — which typically aligns the newly focused element flush with the bottom scrollport edge, i.e. exactly under the pill. 2.4.11 requires that the focused component not be entirely hidden by author-created content; a 36px-tall pill over a ~64px row generally leaves a sliver visible, so this is closer to 2.4.12 (AAA, "not obscured at all") in the strictest reading — but it is a real degradation either way, and it's cheap to fix properly.

Suggested fixes (in increasing order of depth):

1. Cheap and correct for the keyboard case: add scroll-padding-bottom to the scroll container so the browser never scrolls a focused element into the band the pill occupies. Note this must go on whatever element actually scrolls — .AccountView overrides .View__content to overflow: visible, and the FloatingAddButton comment states the document itself scrolls on Home, so .multi-pane-slider__pane having overflow: auto may not be the live scrollport. Worth confirming with document.scrollingElement before picking the selector.

   // alongside the existing padding-bottom
   scroll-padding-bottom: pxToRem(88px);

2. Also fixes the pointer case: give the pill pointer-events handling so it never eats a click meant for a row — e.g. wrap it in a pointer-events: none positioning container with pointer-events: auto restored on the pill itself. This narrows the dead zone to the pill's actual bounds rather than any padding/hit-slop around it, but does not eliminate it; the pill is genuinely on top of the row it covers.

3. Root cause: make the pill hide on scroll-down and reappear on scroll-idle / scroll-up (the common pattern for bottom-pinned FABs), or anchor it to the bottom of the pane rather than the viewport so it participates in layout. Bigger change and a design call, so only worth it if the pill turns out to be visually in the way in practice.

Note on the code comment: views/Account/styles.scss describes the pill as "an absolutely-positioned overlay" — it is position: fixed, and the distinction is exactly why the padding doesn't fully solve the problem. Worth correcting so the next reader doesn't infer the padding is sufficient.

[piyalbasu]

History becomes an icon-only control with no visible label

Accessibility — moderate, discoverability + assistive-tech quality. Not a merge blocker.

TL;DR: History used to be a labelled tile — an icon with the word "History" underneath it. In the new header it's a bare clock icon, and the only thing that names it is a browser tooltip on hover. Tooltips don't appear for touch users or keyboard users, and some screen reader setups don't read them, so the control is harder to identify than it was. This matches how the neighbouring options and network buttons already work, so it's a consistency question for the team rather than a new defect introduced here — but it's worth a conscious call, since History moved from the labelled group into the unlabelled one.

---

Detailed explanation (for agents)

Root cause: the control moved from a NavLink with a visible <Text> label into an SDS NavButton, which exposes no aria-label prop:

freighter/extension/src/popup/components/account/AccountHeader/index.tsx

Lines 234 to 247 in 0ace8b0

	<div data-testid="nav-link-account-history">
	<NavButton
	showBorder
	title={t("View history")}
	id="nav-btn-history"
	icon={<Icon.ClockRewind />}
	onClick={() => {
	emitMetric(METRIC_NAMES.historyFullHistoryOpened, {
	source: "account_header",
	});
	navigateTo(ROUTES.accountHistory, navigate);
	}}
	/>
	</div>

NavButton in @stellar/design-system@3.2.8 renders exactly this:

<button id={id} className={`NavButton ${showBorder ? "NavButton--border" : ""}`}
        title={title} onClick={onClick} disabled={disabled}>
  {icon}
</button>

and the icon assets carry no <title> element:

<!-- build/assets/icons/clock-rewind.svg — same shape as plus.svg / x.svg -->
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="currentColor">
  <path d="…" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"/>
</svg>

So the accessible name resolves entirely through the title attribute. That is a valid name source — the accname spec uses title as the last-resort fallback, and both NVDA and VoiceOver will announce it — so this is not a 4.1.2 Name, Role, Value failure, and no automated checker will flag it. The cost is real but softer:

• title tooltips never render on touch, and never render on keyboard focus (only hover), so keyboard and touch users get no label at all.
• title is suppressed in some AT verbosity configurations.
• 2.5.3 Label in Name doesn't apply (there's no visible text label to mismatch), but the cognitive-accessibility argument for a visible label stands: three adjacent unlabelled circles (options …, history, network globe) is a lot to disambiguate by glyph alone.

Target size is fine — the header override sets these to 32×32, comfortably over the 24×24 required by 2.5.8.

Suggested fixes (in increasing order of depth):

1. Do nothing, deliberately. It's consistent with the existing options and network buttons, and the design calls for an icon row. If this is the decision, no code change — just worth recording so the next a11y sweep doesn't re-litigate it.
2. Strengthen the name without changing the visual: wrap with an explicit label, since NavButton won't forward one:

   <div data-testid="nav-link-account-history" role="none">
     <span id="nav-btn-history-label" className="sr-only">{t("View history")}</span>
     <NavButton … />
   </div>

   or add aria-label support to NavButton upstream in SDS, which fixes all three header buttons at once and is probably the right home for it.
3. Root cause: keep a visible label under the icon, as the old tile had. This conflicts with the Figma header design, so it's a design conversation, not a code fix.

[piyalbasu]

Add Collectible: "Show hidden" doesn't announce that it opens a panel, and the helper text reads out of order

Accessibility — minor, two small polish items on the same screen. Not a merge blocker.

TL;DR: Two things on the new Add Collectible layout. First, "Show hidden" opens a slide-up panel, but nothing tells a screen reader that's what will happen — it's announced as an ordinary button, so the panel appearing is a surprise. Second, the sentence explaining what the screen is for ("If a collectible is missing from your wallet, you can manually add it here") is placed after the "Show hidden" button, so a screen reader user hears the unrelated action before they hear the explanation of the field they just landed on.

Worth noting the positive here too: making "Show hidden" a real <button> instead of the clickable div it replaced is a genuine keyboard-accessibility improvement — it's now reachable by Tab and activates on Enter/Space, which the old dropdown item never did.

---

Detailed explanation (for agents)

Root cause: both items live in the same block:

freighter/extension/src/popup/views/AddCollectibles/index.tsx

Lines 212 to 224 in 0ace8b0

	<button
	type="button"
	className="AddCollectibles__show-hidden"
	data-testid="hidden-collectibles-btn"
	onClick={() => setIsHiddenCollectiblesOpen(true)}
	>
	{t("Show hidden")}
	</button>
	<div className="AddCollectibles__helper-text">
	{t(
	"If a collectible is missing from your wallet, you can manually add it here.",
	)}
	</div>

1. Missing dialog affordance. The button toggles isHiddenCollectiblesOpen, which mounts <HiddenCollectibles isOpen={…} /> — a sheet. Nothing on the trigger advertises that. Per the ARIA authoring practices a control that opens a dialog should carry aria-haspopup="dialog", and if the disclosure state is meaningful, aria-expanded. Neither is present, so AT announces "Show hidden, button" and the user has no warning that focus context is about to change.

2. Reading order. DOM order is FormRows (the contract-address input) → <button>Show hidden</button> → helper text. The helper text is descriptive copy about the input, but it is neither adjacent to the input nor programmatically associated with it, so a screen reader user tabbing from the input hears the "Show hidden" action first and only reaches the explanation afterwards — by which point it reads as commentary on the button rather than the field. Sighted users resolve this instantly from layout; AT users don't get that cue.

Suggested fixes (in increasing order of depth):

1. Cheap: add the dialog affordance to the trigger.

   <button
     type="button"
     className="AddCollectibles__show-hidden"
     data-testid="hidden-collectibles-btn"
     aria-haspopup="dialog"
     aria-expanded={isHiddenCollectiblesOpen}
     onClick={() => setIsHiddenCollectiblesOpen(true)}
   >
     {t("Show hidden")}
   </button>

2. Also cheap, fixes the ordering: move the helper-text div above the button so DOM order matches its meaning. If the Figma layout requires the button to sit visually above the text, keep the DOM order semantic and reorder visually with flex order rather than reordering the DOM — never the other way round.
3. Most correct: associate the copy with the field it describes instead of leaving it as free-floating text, so it's announced when focus enters the input:

   <Input … aria-describedby="add-collectible-helper" />
   …
   <div id="add-collectible-helper" className="AddCollectibles__helper-text">…</div>

   aria-describedby works across DOM distance, so this fixes the ordering problem regardless of where the text physically sits.

Verified separately, no action needed: type="button" is set, so the control does not submit the enclosing Formik <Form>; and the SCSS strips border/background/appearance but leaves outline alone, so the default focus-visible ring survives.

[piyalbasu]

Approved with a couple of small accessibility improvements that would be nice to add!