[scheduler] Improve event popup interactions and toggle behavior by mustafajw07 · Pull Request #22538 · mui/mui-x

mustafajw07 · 2026-05-20T19:22:07Z

Closes #21921

Allow switching between events with a single click while popup is open
Make clicking the active event toggle and close its popup
Close popup on empty calendar click without triggering event creation
Preserve normal single-click event creation when no popup is open
Apply behavior across EventCalendar views and EventTimeline

Changelog

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

… and EventDialog components

…s-and-calendar Signed-off-by: Mustafa Jawadwala <mustafajw07@gmail.com>

…ingEventsPlugin and fix errors type

code-infra-dashboard · 2026-05-21T18:42:11Z

Deploy preview

https://deploy-preview-22538--material-ui-x.netlify.app/

Bundle size

Bundle	Parsed size	Gzip size
@mui/x-data-grid	0B^(0.00%)	0B^(0.00%)
@mui/x-data-grid-pro	0B^(0.00%)	0B^(0.00%)
@mui/x-data-grid-premium	0B^(0.00%)	0B^(0.00%)
@mui/x-charts	0B^(0.00%)	0B^(0.00%)
@mui/x-charts-pro	0B^(0.00%)	0B^(0.00%)
@mui/x-charts-premium	0B^(0.00%)	0B^(0.00%)
@mui/x-date-pickers	0B^(0.00%)	0B^(0.00%)
@mui/x-date-pickers-pro	0B^(0.00%)	0B^(0.00%)
@mui/x-tree-view	0B^(0.00%)	0B^(0.00%)
@mui/x-tree-view-pro	0B^(0.00%)	0B^(0.00%)
@mui/x-license	0B^(0.00%)	0B^(0.00%)

Details of bundle changes

Check out the code infra dashboard for more information about this PR.

mj12albert · 2026-05-22T12:06:30Z

+        const dataId = (data as any)?.id;
+        const currentId = (currentData as any)?.id;
+        if (isOpen && dataId != null && dataId === currentId) {
+          onClose();


Codex finding, recurring occurrences with the same event id cannot be switched in one click:

the toggle logic compares only data.id. Premium recurring occurrences share the event id and differ by occurrence.key (eventId::dateKey), so clicking a different occurrence of the same recurring event closes the dialog instead of opening the clicked occurrence.

I’ve updated the logic to account for recurring occurrences as well.

mj12albert · 2026-05-22T12:07:41Z

+   * Sets the ID of the event currently open in the event dialog.
+   * Pass `null` to clear the open event.
+   */
+  public setOpenEventId = (eventId: SchedulerEventId | null) => {


This seems to only change the store state but doesn't open the dialog?

I’ve updated the implementation to ensure the dialog open state is handled correctly alongside the selected event state.

mj12albert · 2026-05-22T12:09:34Z

+      if (!(node instanceof Element)) {
+        continue;
+      }
+      if (node.matches('[data-event-dialog-trigger]')) {


This seems a bit loose, not sure if it's a realistic scenario but if there are 2 schedulers on the page, clicking an event in scheduler B while scheduler A’s dialog is open will bypass A’s click-away close and can leave both dialogs open

…methods and update event dialog integration

…rativeRef initialization

…r interactions

…s-and-calendar

mustafajw07 · 2026-05-27T08:26:26Z

@rita-codes / @mj12albert
Requested changes have been updated. Please review and let me know if any further changes are needed.

Thanks.

…s-and-calendar

rita-codes · 2026-06-08T09:19:42Z

Thanks for working on this!!
One thing about the expected behavior here 👀
I checked the preview and one thing is missing: "Clicking on an empty area of the calendar should close the popup without creating a new event."
Right now if you click in an empty area the popup closes but it's creating a new event, could you take a look?
Thanks!!

Screen.Recording.2026-06-08.at.11.18.59.mov

…s-and-calendar

…ehavior

mustafajw07 · 2026-06-08T17:59:53Z

I checked the preview and one thing is missing: "Clicking on an empty area of the calendar should close the popup without creating a new event."
Right now if you click in an empty area the popup closes but it's creating a new event

I've fixed the issue now.

Clicking on an empty area of the calendar will close the popup without creating a new event. I verified the behavior in the preview and it is working as expected.

…ng dialog

rita-codes · 2026-06-09T15:32:14Z

Thanks for the work on this @mustafajw07! 🙏 I tested it and found a blocking issue, and digging into it made me question the overall approach for closing the popup. Let me walk through how I got there.

The bug

When you open the recurrence tab and pick an option from the frequency dropdown, the popup closes. Same thing happens with the resource/color Select (ResourceAndColorSection.tsx).

Root cause

The popup now closes via a ClickAwayListener wrapping the <Dialog>. A ClickAwayListener only "sees" the subtree of the node it wraps — but @mui/material/Select (and pickers, menus, etc.) render their popup in a separate portal at body level. So clicking a menu item lands outside the dialog's subtree → onClickAway fires → onClose().

This isn't a one-off: it affects every portaled overlay inside the dialog. The !isScopeDialogOpen guard on the ClickAwayListener is actually the same bug already patched by hand for one specific case (the recurring scope dialog). The recurrence/resource dropdowns are the same problem, unpatched.

Why I don't think narrow patches are the way

The current close logic is opt-out: close on any click, unless it's inside the dialog, or an event trigger, or the scope dialog…. That list of exceptions can never be complete:

Every new internal overlay (pickers, menus, autocompletes) breaks it.
More importantly — the form is meant to be extensible with custom fields. Any custom field a consumer drops in (their own Select, a third-party date picker, etc.) opens a portal we don't control, which will read as an "outside click" and close the dialog.

I looked into whether moving to base-ui's Popover (useDismiss + FloatingTree, both already available as deps) would fix it. It solves the internal overlays, but not custom fields: the FloatingTree only protects floating-ui descendants, and arbitrary consumer portals won't be in the tree. So no overlay primitive — Material or base-ui — robustly solves this as long as the close logic is "close on outside click".

Proposed direction: opt-in dismissal

Instead of "close on any outside click, minus a list of exceptions", close only on explicit, intended gestures (an allowlist), which are finite and we fully control:

Esc
the close button
clicking another event (switch)
clicking the calendar surface (empty cell)

Any field popup (custom or internal) floats at body level — it's neither on the calendar surface nor another event — so it never triggers a close. This is robust against arbitrary custom portals and reuses the calendar click handler that already exists in useEventCreation.ts (it already knows openEventId). The model becomes "the calendar tells the dialog to close" rather than "the dialog listens to the whole document". As a bonus it makes pointerEvents: none, the data-event-dialog-trigger + composedPath scanning, and the scope-dialog special-case unnecessary.

@flaviendelangle @noraleonte — before @mustafajw07 invests more here, could you confirm how you see this? The chain of reasoning was: recurrence dropdown closes the popup → it's a portal/ClickAwayListener issue, not isolated → base-ui's tree-aware dismiss doesn't cover custom fields either → so the close logic itself (the opt-out approach) is the wrong shape, and an opt-in allowlist of gestures driven by the calendar is more robust for an extensible form. Does that match how you'd want event-dialog dismissal to work, especially with custom fields in mind?

A few smaller things I also noted, independent of the above:

Focus trap vs. non-modal: aria-modal="false" + transparent/pointerEvents:none backdrop, but the <Dialog> keeps its default focus trap (no disableEnforceFocus/disableAutoFocus) — contradictory for a popup meant to let you interact with the calendar behind it.
Toggle by key with two formats: trigger open uses occurrence.key, imperative open (setOpenEventId) uses String(processed.id) — they don't match, so toggling an event that was opened via the public API reopens instead of closing.
setOpenEventId opens with no anchor (EMPTY_ANCHOR_REF), so programmatic open isn't positioned.
No test for the failing case: there's no test that opens a Select/picker inside the dialog and asserts it stays open — that test would currently fail.

mustafajw07 · 2026-06-09T18:53:34Z

Thanks for the detailed analysis. I agree this seems more like a dismissal-strategy question than an isolated bug. I'll wait for feedback from @flaviendelangle / @noraleonte on the proposed direction before making larger changes.

mustafajw07 added 4 commits May 19, 2026 21:07

[dialog] Implement openEventId management for event dialog interactions

de44e80

[scheduler][eventDialog] Add openEventId management to SchedulerStore…

8774b84

… and EventDialog components

Merge branch 'master' into feature/21921-Allow-interacting-with-event…

eaf622f

…s-and-calendar Signed-off-by: Mustafa Jawadwala <mustafajw07@gmail.com>

[scheduler][eventDialog] updated EventDialog and test cases

b0c4149

mustafajw07 mentioned this pull request May 20, 2026

[scheduler] Allow interacting with events and calendar while event popup is open #21921

Open

zannager added the scope: scheduler Changes related to the scheduler. label May 21, 2026

[scheduler][SchedulerStore] Refactor SchedulerState to include recurr…

517b0f3

…ingEventsPlugin and fix errors type

mj12albert reviewed May 22, 2026

View reviewed changes

mustafajw07 added 4 commits May 26, 2026 19:49

[scheduler][createModal] Enhance modal functionality with imperative …

689dfc8

…methods and update event dialog integration

refactor(EventDialog): format imports and improve readability of impe…

3457d1a

…rativeRef initialization

[test] Update EventDialog tests to use mouseDown for ClickAwayListene…

15dd7be

…r interactions

Merge branch 'master' into feature/21921-Allow-interacting-with-event…

31c1086

…s-and-calendar

mustafajw07 added 5 commits May 29, 2026 10:55

Merge branch 'master' into feature/21921-Allow-interacting-with-event…

a4ce114

…s-and-calendar

Merge branch 'master' into feature/21921-Allow-interacting-with-event…

fd651ff

…s-and-calendar

Merge branch 'master' into feature/21921-Allow-interacting-with-event…

6972f29

…s-and-calendar

Merge branch 'master' into feature/21921-Allow-interacting-with-event…

df990f1

…s-and-calendar

Merge branch 'master' into feature/21921-Allow-interacting-with-event…

f4cb40b

…s-and-calendar

mustafajw07 added 2 commits June 8, 2026 23:12

Merge branch 'master' into feature/21921-Allow-interacting-with-event…

cb15dc0

…s-and-calendar

[fix] Update ClickAwayListener mouse event to 'onClick' for correct b…

2d28094

…ehavior

[fix] Update ClickAwayListener interaction to use 'onClick' for closi…

3e61437

…ng dialog

rita-codes added the type: enhancement It’s an improvement, but we can’t make up our mind whether it's a bug fix or a new feature. label Jun 9, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[scheduler] Improve event popup interactions and toggle behavior#22538

[scheduler] Improve event popup interactions and toggle behavior#22538
mustafajw07 wants to merge 17 commits into
mui:masterfrom
mustafajw07:feature/21921-Allow-interacting-with-events-and-calendar

mustafajw07 commented May 20, 2026 •

edited

Loading

Uh oh!

code-infra-dashboard Bot commented May 21, 2026 •

edited

Loading

Uh oh!

mj12albert May 22, 2026

Uh oh!

mustafajw07 May 26, 2026

Uh oh!

mj12albert May 22, 2026

Uh oh!

mustafajw07 May 26, 2026

Uh oh!

mj12albert May 22, 2026

Uh oh!

mustafajw07 commented May 27, 2026

Uh oh!

rita-codes commented Jun 8, 2026

Uh oh!

mustafajw07 commented Jun 8, 2026

Uh oh!

rita-codes commented Jun 9, 2026

Uh oh!

mustafajw07 commented Jun 9, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

mustafajw07 commented May 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Closes #21921

Changelog

Uh oh!

code-infra-dashboard Bot commented May 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Deploy preview

Bundle size

Uh oh!

mj12albert May 22, 2026

Choose a reason for hiding this comment

Uh oh!

mustafajw07 May 26, 2026

Choose a reason for hiding this comment

Uh oh!

mj12albert May 22, 2026

Choose a reason for hiding this comment

Uh oh!

mustafajw07 May 26, 2026

Choose a reason for hiding this comment

Uh oh!

mj12albert May 22, 2026

Choose a reason for hiding this comment

Uh oh!

mustafajw07 commented May 27, 2026

Uh oh!

rita-codes commented Jun 8, 2026

Uh oh!

mustafajw07 commented Jun 8, 2026

Uh oh!

rita-codes commented Jun 9, 2026

The bug

Root cause

Why I don't think narrow patches are the way

Proposed direction: opt-in dismissal

Uh oh!

mustafajw07 commented Jun 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

mustafajw07 commented May 20, 2026 •

edited

Loading

code-infra-dashboard Bot commented May 21, 2026 •

edited

Loading

mustafajw07 commented Jun 9, 2026 •

edited

Loading