Closed Bug 2063604 Opened 1 month ago Closed 1 month ago

Whene side-by-side exp layout is enabled, the "Change size" widget context menu item is missing

Categories

(Firefox :: New Tab Page, defect)

defect

Tracking

()

RESOLVED FIXED
156 Branch
Tracking Status
firefox-esr115 --- unaffected
firefox-esr140 --- unaffected
firefox-esr153 --- unaffected
firefox154 --- unaffected
firefox155 --- unaffected
firefox156 --- fixed

People

(Reporter: maxx, Assigned: maxx)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [hnt])

Attachments

(1 file)

Assumptions:

  • You have sections stories/content feed enabled
  • You have widgets enabled (See below for enabling them)
  • You have new tab nova enabled

Note – If you dont have widgets enabled, follow the steps below to access the devtools menu and then:
Click "Widgets" section to expand
Click "Enable All" or whichever widgets you want

To enable:

  1. In about:config, enable the pref browser.newtabpage.activity-stream.asrouter.devtoolsEnabled
  2. Open New tab
  3. Click "Wrench" (not the pencil) icon in bottom right
  4. Expected: The dev tools should open
  5. Click on "Page layout (experimental)" section to expand
  6. Select any of the following layouts to try them out
  7. Expected: The layout should change on new tab with that specific layout, with widgets visible
  8. Click "..." on any widget
  9. Expected: The "Change size" menu item should be visible/working
  10. Actual: The change size menu is missing.

Localized this to one line in the bug 2061741 landing (7012f7fe5513).

Root cause. In browser/extensions/newtab/content-src/components/Widgets/Widgets.jsx the changeset added !sideBySideActive to showWidgetsSizeToggle so the row-level header maximize button is hidden in the one-card-wide column — but the next line is const widgetsMayBeMaximized = showWidgetsSizeToggle;, and widgetsMayBeMaximized is the prop each widget uses to gate its <SizeSubmenu>. So one flag now suppresses two unrelated controls, and "Change size" disappears from Lists, FocusTimer, Crossword, PictureOfTheDay, Privacy and Stocks.

Worth noting the symptom is inconsistent: Clocks.jsx renders <SizeSubmenu> ungated, and Weather/SportsWidget read widgets.system.maximized directly, so those three still show "Change size" under side-by-side.

Per-widget sizing is meaningful here, so hiding the submenu isn't a defensible substitute: the widgets track is --col-span(4) in every side-by-side variant, and medium vs large differ only in row span (2 vs 4) in _WidgetWrapper.scss. resolveWidgetSize in WidgetsRegistry.mjs is independent of these flags, so a user's existing widgets.<id>.size = "large" already renders as large-widget in that column today — only the UI to change it is gone.

Proposed fix, in Widgets.jsx — decouple the two constants:

const widgetsMayBeMaximized =
  nimbusMaximizedTrainhopEnabled || prefs[PREF_WIDGETS_SYSTEM_MAXIMIZED];
// Row-level maximizing makes no sense in a single-widget-wide column, so
// that slot gets an add button instead.
const showWidgetsSizeToggle = !sideBySideActive && widgetsMayBeMaximized;

Two knock-ons to decide deliberately:

  • Crossword.jsx reuses widgetsMayBeMaximized for auto-grow ("never render a large-widget on a layout that can't host it"). Decoupling lets it grow mid-puzzle in the side-by-side column. That column does host large, so this is likely fine — but if it should be suppressed, gate it on !sideBySideActive explicitly rather than on the maximize flag.
  • widgetSize at line 299 is telemetry-only (4 call sites). Flipping the flag changes the reported row-level widget_size from large back to medium under side-by-side; derive it from sideBySideActive if the experiment analysis depends on it.

Tests. Nothing currently covers this: browser_newtab_side_by_side_layout.js is geometry-only, and the side-by-side cases in Widgets.test.jsx only assert the add-widgets button. A fix should add a Jest case asserting #toggle-widgets-size-button is absent and the per-widget size submenu is present when side-by-side is active.

Suggested severity S3: a functional control is missing, but only in an experimental layout variant, and switching variant restores it.

(Reasoned from the source; not built or run.)


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.

Severity: -- → S3
Status: NEW → RESOLVED
Closed: 1 month ago
Resolution: --- → FIXED
Target Milestone: --- → 156 Branch
QA Whiteboard: [qa-triage-done-c157/b156]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: