Docs: Declare the font on overlay surfaces so docs tooltips are not left to inherit

[valentinpalkovic]

Closes #

What I did

Every tooltip on a docs page renders in the browser's default serif. Not a Storybook font at all - Times.

The cause is that overlays render through a portal at the document root, and they were left to inherit their typography from wherever that portal lands. In the manager the root carries Storybook's font stack, so tooltips looked correct and nobody noticed. In the preview iframe the root carries nothing, so they fall back to the UA default. The same gap means a user's own preview styles can reach into Storybook's overlays.

Three overlay surfaces now state their own font-family instead of inheriting it.

Measured, on the "Open canvas in new tab" button of any autodocs page

	getComputedStyle(tooltip).fontFamily
Manager (addon panel)	"Nunito Sans", -apple-system, …
Docs iframe, before	Times
Docs iframe, after	"Nunito Sans", -apple-system, …

The preview iframe's document.body computes font-family: Times either way. The point of the change is that the overlay no longer depends on it.

The same tooltip, same crop

Before:

After:

In context:

The change

 const Note = styled.div(({ theme }) => ({
+  // Portal-rendered, so it cannot rely on inheriting a base font: the preview iframe root has
+  // none, and a user's own styles may sit there instead.
+  fontFamily: theme.typography.fonts.base,
   padding: '2px 6px',

Seven lines in total, the same idea in TooltipNote, Popover and WithTooltip's chrome. Nothing changes in the manager, where the computed value was already this stack.

Not covered here

ListItem (the content of TooltipLinkList) has the same gap, but it renders as a <button>, whose UA font is a separate problem, and it does not appear on a docs page today. Worth a follow-up rather than an unverified fix bundled into this one.

Checklist for Contributors

Testing

The changes in this PR are covered in the following automated tests:

• stories
• unit tests
• integration tests
• end-to-end tests

Note

This is a computed-style regression that no current test asserts, and the existing tooltip stories render in the manager, where the bug never reproduced. I verified it by hand in a sandbox, measured above. A test that pins overlay typography would need to run inside the preview iframe; happy to add one if a reviewer wants it.

Manual testing

1. Generate any sandbox: yarn task sandbox --template angular-vite/default-ts --start-from auto

2. Run yarn storybook and open any component's Docs page

3. Hover the "open canvas in new tab" icon in the top-right of a story canvas

4. Before this change the tooltip renders in a serif face; after it, in Storybook's sans stack

5. To confirm the root cause rather than the symptom, run this in the console and note that the body font is unchanged either way:

   const d = document.getElementById('storybook-preview-iframe').contentDocument;
   getComputedStyle(d.body).fontFamily;                      // "Times"
   getComputedStyle(d.querySelector('[role="tooltip"] > *')).fontFamily;

Documentation

• Add or update documentation reflecting your changes
• If you are deprecating/removing a feature, make sure to update
  MIGRATION.MD

Checklist for Maintainers

• When this PR is ready for testing, make sure to add ci:normal, ci:merged or ci:daily GH label to it to run a specific set of sandboxes. The particular set of sandboxes can be found in code/lib/cli-storybook/src/sandbox-templates.ts

• Declare whether manual QA will be needed for this PR during the next release, through qa:needed or qa:skip

• Make sure this PR contains one of the labels below:

  Available labels

  • bug: Internal changes that fixes incorrect behavior.
  • maintenance: User-facing maintenance tasks.
  • dependencies: Upgrading (sometimes downgrading) dependencies.
  • build: Internal-facing build tooling & test updates. Will not show up in release changelog.
  • cleanup: Minor cleanup style change. Will not show up in release changelog.
  • documentation: Documentation only changes. Will not show up in release changelog.
  • feature request: Introducing a new feature.
  • BREAKING CHANGE: Changes that break compatibility in some way with current major version.
  • other: Changes that don't fit in the above categories.

[github-actions]

	Fails
🚫	PR is not labeled with one of: ["qa:needed","qa:skip","qa:success"]

Generated by 🚫 dangerJS against ca90cca

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: d4201673-d8b9-48ea-8279-d65cd8451bb6

📥 Commits

Reviewing files that changed from the base of the PR and between b5383b7 and ca90cca.

📒 Files selected for processing (3)

• code/core/src/components/components/Popover/Popover.tsx
• code/core/src/components/components/tooltip/TooltipNote.tsx
• code/core/src/components/components/tooltip/WithTooltip.tsx

Included review availability: 0 reviews are currently available. Your included PR review attempts over the past 7 days set your current allowance at 1 review per hour.

---

Walkthrough

Chrome-enabled popovers and tooltips now use the theme’s base typography font family.

Changes

Chrome Typography

Layer / File(s)	Summary
Apply theme base font family code/core/src/components/components/Popover/Popover.tsx, code/core/src/components/components/tooltip/TooltipNote.tsx, code/core/src/components/components/tooltip/WithTooltip.tsx	Chrome-enabled popovers and tooltips set fontFamily from theme.typography.fonts.base.

Merge Risk: ⚪ Minimal · up to ca90c

This localized change makes portal-rendered documentation overlays use Storybook's font instead of inheriting the browser default, with no actionable merge-blocking risk remaining beyond normal checks and review.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

---

_{Comment @coderabbitai help to get the list of available commands.}

[JReinhold]

This looks correct to me. I would have expected some docs root element to have the font family, but I see the individual typography elements have the font-family directly applied. I assume this is to try and minimize how much of our SB styling leaks into user-defined components and stories.