2060927 - Hovered item borders are not rounded in widget context menus

Status: NEW

(Firefox :: New Tab Page, defect)

Description

[Selim Şumlu]

Attachment: widget context menu.jpg

Steps to reproduce

1. Enable widgets on Firefox Home.
2. Disable Nova.
3. Click on the three-dot button to open the context menu of any widget.
4. Hover over the first and last items of the menu.

Expected result

Corners of the first and last items should be rounded.

Comment 1

[Selim Şumlu]

My inital attribution to Nova was wrong. This is actually not reproducible on Nova. It only affects the older UI.

Comment 2

[Jonathan Kew [:jfkthame]]

Interestingly, I see this with the menus on individual widgets (such as Weather), but not with the similarly-styled menu for the Widgets section of the home page (with the Hide Widgets / Manage Widgets / Learn More options).

This seems like a front-end design/styling issue; moving to Firefox:Theme.

Comment 3

[Stephen Thompson [:sthompson]]

I'm going to move this to New Tab Page first in case it's specific to that page.

The screenshots show a <panel-item> element with the hover background bleeding outside of the rounded corners of the <panel-list>. Comment 4 mentioned that this is not coming from the Nova redesign, but the screenshots show a Nova visual design, so I'm guessing that this reflects the following combination of prefs:

• browser.nova.enabled = false
• browser.newtabpage.activity-stream.nova.enabled = true (which has been default for several months)

Comment 4

[Stephen Thompson [:sthompson]]

Also noting that bug 2057169 is similar but specific to the Nova redesign. I'm not sure whether the patch on that bug will affect the New Tab Page behavior.

Comment 5

[Scott [:thecount] Downe]

I think it could be fixed, or at least I'm not seeing it now in nightly.

Comment 6

[Reem Hamoui]

Hey Selim, could you confirm on your end if this issue is still happening or if it's fixed?
We're currently unable to reproduce it on our end.

Comment 7

[Selim Şumlu]

(In reply to Reem Hamoui from comment #6)

Hey Selim, could you confirm on your end if this issue is still happening or if it's fixed?
We're currently unable to reproduce it on our end.

I can still reproduce it after setting browser.nova.enabled to false.

Comment 8

[Hackbot]

Re comment 4: the patch on bug 2057169 won't affect this — it only changed the XUL menupopup radius in toolkit/themes/shared/popup.css. The widget menus on about:newtab are the HTML <panel-list>/<panel-item> custom elements, a separate code path, which is why it still reproduces.

Suspected root cause: a panel-list normally clips its content to its rounded corners via overflow-y: auto on :host (toolkit/content/widgets/panel-list/panel-list.css#42), but that clipping is switched off for any list that contains a submenu: :host([has-submenu]) { overflow: visible; } (panel-list.css#46-48), with the attribute set on the parent list by panel-list.mjs#770-771. Every per-widget menu has a submenu item — "Change size" / "Move" from browser/extensions/newtab/content-src/components/Widgets/WidgetMenuFooter.jsx#66-72 — while the Widgets section menu has none (Widgets.jsx#604-617), which matches comment 2 exactly. With browser.nova.enabled=false the item button gets --panel-item-button-border-radius: 0 and --panel-item-button-margin: 0, since the rounded/inset values only apply under @media -moz-pref("browser.nova.enabled") (panel-item.tokens.css#15-33), so the square hover background paints over the corner once the clip is gone. With Nova on, the item's inline margin and own radius keep the highlight clear of the corner — hence not reproducible there.

Proposed fix, in toolkit rather than newtab (it affects every submenu-bearing panel-list):

1. Stop lifting the clip unconditionally — only escape overflow while a submenu is actually open: toggle e.g. submenu-open on the parent list from the submenu panel's shown/hidden handling in panel-list.mjs#975-990 and scope the overflow: visible rule to that attribute.
2. Belt and braces, round the outer corners of the first/last item's button in panel-item.css (roughly calc(var(--panel-list-border-radius) - var(--panel-padding-block))) so the highlight can't bleed regardless of clipping.

Longer term the submenu could move to the top layer (popover + anchor positioning) so the parent never has to give up clipping; bug 2010864 deliberately left submenus out of the popover conversion.

Closest existing coverage of this path is toolkit/content/tests/widgets/test_panel_list_popover.html — it builds a submenu but asserts nothing about corner rendering. Not verified by running the code.

---

Suggested severity: S4
Purely cosmetic: a hover highlight overlapping the menu's rounded corner, with no effect on the menu's function and only in the non-Nova configuration.

---

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 9

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:thecount, could you have a look please?

For more information, please visit BugBot documentation.