2016281 - (finish-responsive-sidebar) Finish responsiveness work on smartbar

Status: NEW

(Core :: Machine Learning: Frontend, enhancement)

Description

[Dan Mosedale (:dmosedale, :dmose)]

We need make the Smartbar more responsive so that it's more usable at different widths and different contexts.

There are mocks with a few accompanying notes below this rectangle in Figma.

Acceptance criteria:

These criteria should be validated for both new tab and the sidebar:

1. When the dropdown width > 280px, each dropdown entry should be a single line -- see mocks 1, 2, and 4 (this is probably at least in part because the smartbar is currently triggering uidensity="compact" related rules at a shorter width than the URL bar).
2. Tab title and URL in that single line should be split so that at least the domain is visible -- see the note below mock 1
3. When the dropdown width <= 280px the each dropdown entry should be split across two lines -- see mocks 3, 5, and 6.

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

See the "Responsive" row at the bottom of https://www.figma.com/design/5KuePTGmOEUFyCHBHCsGim/AI-Mode-%E2%80%94%C2%A0MVP-Scope-Design?node-id=4450-63730&m=dev for details on what needs to happen; will distill these into acceptance criteria shortly.

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: WIP: Bug 2016281 - Add smartbar compact mode test and container query scaffolding

• Add test asserting smartbar uses compact min-height (26px) when
  wrapper is constrained below 280px, and restores default (32px)
  when width increases
• Add container query context on #smartbar-wrapper
• Add initial @container rule in smartbar.css

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

OK, I've uploaded a patch that implements a not-yet-working test for this in the new tab page. First step will be to make that fail correctly.

What follows is the tail end of a lightly edited tail end of a conversation with claude about a way forward. :mak, does this look reasonable to you?

For the assignee, go to the string DO THIS FIRST in the text below to verify that this strategy is viable.

Note that I think it's ok to move this forward before
❯ Summarize the proposed plan.

⏺ Plan: Make smartbar responsive using container size queries + custom properties

1. Refactor shared urlbar CSS — In urlbarView.css, replace the ~3-4 hardcoded
   compact values (like min-height: 32px) with custom properties (like
   var(--urlbarView-row-min-height)). Define defaults and uidensity="compact"
   overrides in urlbar-variables.css. Normal browser behavior unchanged.
2. Extend the existing @container block in smartbar.css — Add those new custom
   properties alongside the existing --urlbar-min-height override, so all compact
   styles activate when the container is narrow.
3. Keep everything already on the branch — The container context in
   ai-window.css, the @container block in smartbar.css, and the test all stay as-is
   (test may get extended to check additional properties).

Example:

@container smartbar-container (max-width: 280px) {
.smartbar {
--urlbar-min-height: max(26px, 1.4em);
--urlbarView-row-min-height: auto;
/* etc. for the few other compact values */
}
}

This is just a plain size container query — already working, already in use in
this codebase. The only prerequisite is refactoring the handful of hardcoded
compact values in urlbarView.css into custom properties so the size query has
something to set.

That gives you: pure CSS, no JS, no style queries, no rule duplication, properly
scoped to the container, and works on all channels today.

❯ so if we do that, does it maek sense to keep any of the code already on this
branch?

❯ pros and cons of this strategy?

⏺ Pros:

• Pure CSS — no JS changes, no ResizeObserver, no async timing concerns
• No rule duplication — the compact styles are defined once via custom
  properties, consumed everywhere
• Properly scoped to the container — no :root side effects, independent per
  instance
• Uses stable, well-supported container size queries (already in use in this
  codebase)
• All existing code on the branch is reusable
• The normal urlbar compact mode (uidensity="compact") continues working — it
  just sets the same custom properties via a different mechanism
• Arguably improves the shared CSS — extracting hardcoded values into custom
  properties makes the density system more flexible generally

Cons:

• Touches shared urlbar CSS files (urlbarView.css, urlbar-variables.css) —
  changes to these affect the normal browser urlbar, not just the smartbar. Needs
  careful review and testing.
• Introduces a subtle coupling: if someone adds a new hardcoded compact style in
  urlbarView.css without also adding a custom property, the smartbar won't pick it
  up. This is the same drift risk as rule duplication, just in a different
  direction — it's easy to miss.
  -> DO THIS FIRST: The custom properties need to be set on .smartbar inside the container query,
  which means they need to cascade down to the urlbar view descendants. Should work
  since they're descendants, but worth verifying the shadow DOM boundaries don't
  block inheritance.

The biggest practical risk is the shared CSS change — it needs to be correct for
the normal urlbar. The refactor itself is small (3-4 properties), but it's a
high-traffic code path.

❯ The refactor is just changing hardcoded numbers to new custom properties, right?

⏺ Right. The existing compact selectors in urlbarView.css set values like
min-height: 32px conditionally based on :root:not([uidensity="compact"]). The
refactor replaces those with min-height: var(--urlbarView-row-min-height),
defines the default and compact values for that property in urlbar-variables.css,
and the behavior is identical. No logic changes, just indirection through a
custom property.