Closes #22758

Summary

DayTimeGrid (the time grid shared by the Week and Day views) reserves a scrollbar-gutter placeholder in the all-day header and the last day-header cell so those columns stay aligned with the scrollable body below. That placeholder is toggled by a hasScroll flag, surfaced as data-has-scroll.

hasScroll was only recomputed when the events changed. It never recomputed when the container resized, so a resize that crossed the body's vertical-overflow threshold without an event change left hasScroll stale, and the all-day header columns drifted from the body columns by about one scrollbar width.

Root cause

hasScroll was measured in a single layout effect keyed only on occurrencesMap, with no resize signal:

useIsoLayoutEffect(() => {
  ...
  setHasScroll(body.scrollHeight > body.clientHeight);
}, [occurrencesMap]); // recomputes on events, not on container size

So a window resize, a side-panel toggle, or any height change that did not also change the events was ignored.

Fix

Extract the measurement into a stable callback and drive it from both signals: the existing layout effect (events) and a ResizeObserver on the body (size). This reuses useResizeObserver from @mui/x-internals, which the sibling MonthView already uses, and mirrors the existing find-and-measure idiom in GridMultiselectMeasurer.

const updateHasScroll = React.useCallback(() => {
  const body = bodyRef.current;
  const allDayHeader = allDayHeaderWrapperRef.current;

  if (!body || !allDayHeader) {
    return;
  }

  setHasScroll(body.scrollHeight > body.clientHeight);
}, []);

useIsoLayoutEffect(updateHasScroll, [occurrencesMap, updateHasScroll]);

useResizeObserver(bodyRef, updateHasScroll);

The layout effect is intentionally kept rather than replaced. A ResizeObserver on the body alone is not guaranteed to catch the all-day-events-grow case in every consumer layout (it only shrinks the body when the container is height-capped), so keeping the occurrencesMap recompute guarantees that path stays covered. The fix is local to DayTimeGrid and benefits both the Week and Day views, since both render this component. No new dependency is added.

Testing

Added a browser test at packages/x-scheduler/src/internals/components/day-time-grid/tests/DayTimeGrid.test.tsx. It is gated with describe.skipIf(isJSDOM) because hasScroll depends on real layout, which jsdom does not implement.

The test renders the week view in a tall host so the body does not overflow (data-has-scroll absent), then shrinks the container through direct DOM mutation so the body overflows without a React re-render, and asserts data-has-scroll appears. Resizing through the DOM rather than a React re-render is deliberate: a rerender re-runs the component and masks the bug, so it would not actually exercise the resize path.

Verified:

• Passes with the fix.
• Fails without the fix (expected ... to have an attribute 'data-has-scroll'), proving it catches the regression.
• pnpm --filter "@mui/x-scheduler" run typescript, pnpm eslint, and the full pnpm test:unit --project "x-scheduler" --run jsdom suite all pass with no regressions.

Run it with:

pnpm test:browser --project "x-scheduler" --run DayTimeGrid

Out of scope

While in this file I noticed two pre-existing, unrelated issues that I deliberately did not change to keep this PR scoped: a malformed selector &:not[data-has-scroll] at DayTimeGrid.tsx:79 (should be &:not([data-has-scroll])), and a dead --has-scroll: 1 custom property at DayTimeGrid.tsx:38. These can be addressed separately.

Changelog

@mui/x-scheduler

• Fix DayTimeGrid so the all-day header scrollbar gutter recalculates on container resize, keeping the header columns aligned with the scrollable body.

Checklist

• I have followed (at least) the PR section of the contributing guide.