2063538 - Arrow icon is displayed below the main message for FR

Status: NEW

(Firefox :: New Tab Page, defect, P3)

Description

[Gabi Cheta [:Gabi] Desktop QA]

Attachment: 2026-08-14_11h23_25.png

Affected versions

• Firefox 156.0a2

Affected platforms

• Windows 11 x64

Steps to reproduce

1. Install a FR Nightly build
2. Enable the privacy widget
3. See the zero trackers UI message

Expected result

• No UI issues are seen on the widget main message

Actual result

• Arrow icon is displayed bellow the main message for FR

Regression range
*New feature

Additional notes

• See the attached

Comment 1

[Hackbot [:hackbot]]

Triage / fix plan (static code analysis — not built or run):

Root cause. The zero-trackers UI is the widget's empty state, which renders a Fluent-populated block paragraph: browser/extensions/newtab/content-src/components/Widgets/Privacy/Privacy.jsx — <p class="privacy-empty-message" data-l10n-id="newtab-privacy-empty">. The arrow is a separate generated box on that paragraph: browser/extensions/newtab/content-src/components/Widgets/Privacy/_Privacy.scss, .privacy-empty-message::after { display: inline-block; … mask: arrow-right.svg }. Because it's an atomic inline at the end of the last line box, a soft-wrap opportunity exists immediately before it, and nothing ties it to the preceding word. en-US happens to fit; the longer FR string, inside the max-width: 75% / text-align: center container (_Privacy.scss#146-154), pushes the arrow onto its own line under the message. This is locale-length-dependent, so other long-string locales (de, es, pt-BR, …) are likely affected too.

Secondary bug in the same rule: _Privacy.scss#162 is vertical-align: center, which is not a valid vertical-align value, so it is dropped at parse time and the arrow falls back to baseline. It's the only vertical-align: center in newtab/content-src.

Proposed fix (CSS only, in _Privacy.scss): drop the ::after inline-block and adopt the pattern already used elsewhere in newtab for a trailing link arrow — paint the icon into reserved padding on the element itself, so it can never be orphaned regardless of string length or line count:

• .privacy-empty-message { padding-inline-end: var(--space-large); background: url('chrome://global/skin/icons/arrow-right.svg') no-repeat right center; -moz-context-properties: fill; fill: currentColor; } plus the :dir(rtl) mirror (arrow-left.svg, background-position: left center), matching Weather/_Weather.scss#53-66 and CustomizeMenu/_CustomizeMenu.scss#534-545.
• Remove the invalid vertical-align line with it.
• Tradeoff for UX to confirm: the arrow then sits at the inline-end edge of the paragraph box, vertically centered against the whole message, rather than immediately after the final word. Adding inline-size: fit-content; margin-inline: auto; to the paragraph keeps it hugging the widest line under text-align: center. If design requires it flush after the last word, the alternative is to keep the arrow inline and accept the wrap risk — there is no reliable way to prevent a break between Fluent-supplied text and a trailing generated inline box.

Sibling .privacy-count-sites (_Privacy.scss#224-240) uses the same mask icon but as an inline-flex item, so it does not have this failure mode.

Regressor. Per Searchfox blame, the ::after arrow rule landed in changeset 7a182976 (2026-08-13, "Bug 2048388 - Add telemetry to privacy widget"), i.e. the day before this report — consistent with "new feature", not a regression from released code.

Tests. No existing test covers this. test/jest/content-src/components/Widgets/Privacy.test.jsx does cover the empty state (.privacy-empty-message presence, shield icon, a.privacy-empty-details click) but runs in jsdom with no stylesheets, so it cannot catch layout; there is no browser-chrome mochitest for the privacy widget at all. Verification will have to be a visual check with a long-string locale (or intl.l10n.pseudo=accented).

Severity: suggest S4 — purely cosmetic, the message and its about:protections link remain fully functional, and it's confined to the widget's empty state. Arguably S3 given it affects every long-string locale rather than a rare configuration; leaving the field for the component owner to set.

---

If you'd like to provide feedback on this comment, please use the 👍 or 👎 reaction.
If you want to categorize your feedback you can add one of the following tags: ai-triage-wrong-file, ai-triage-wrong-cause, ai-triage-hallucination, ai-triage-out-of-scope.

Comment 2

[Helen]

Minor UI issue that doesn't impact functionality, not a launch blocker.