View-switcher dropdown (Reka UI) unresponsive to real clicks in Chrome/Chromium

[palamars]

Description

The view-switcher dropdown (breadcrumb "List ⌄" button, e.g. on the Deals list) does not respond to real mouse clicks in Chrome/Chromium. Two separate failure points, confirmed via both a real-user click, a CDP-simulated click (cloud browser), and Puppeteer's automated click (which dispatches real mousedown/mouseup/click via Input.dispatchMouseEvent, same as a genuine user click):

1. Clicking the dropdown trigger itself does not open the menu. The trigger button (Reka UI DropdownMenuTrigger, e.g. id="reka-dropdown-menu-trigger-v-0-XX") shows no visible reaction to a real click — aria-expanded stays "false", data-state stays "closed", and no menu content is mounted in the DOM. Triggering .click() on the element programmatically via page.evaluate does open the menu correctly, confirming the element itself, its Vue bindings, and click handler are wired up fine — it's specifically the trusted/native click event path that fails.
2. With the menu forced open (via the programmatic click above), clicking an item (e.g. "Kanban") does nothing. The item highlights correctly on hover (so there's no overlay/z-index/hit-testing issue — document.elementFromPoint() at the click coordinates correctly resolves to the target <button>), but a real click on it doesn't select the view: the URL stays on /crm/deals/view/list, the checkmark stays on "List", and the menu doesn't close.

Confirmed working in Firefox — same site, same user, same view. Issue is Chrome/Chromium-specific.

Likely related to known Reka UI Chrome dropdown-click bugs:

• [Bug]: Click to open in DropdownMenu triggers click in the items unovue/reka-ui#366 ("click triggers item click")
• [Bug]: dropdown-menu coordinate problem unovue/reka-ui#1809 ("coordinate problem")

Steps to reproduce

1. Open any list view with a view switcher (e.g. Deals list) in Chrome/Chromium.
2. Click the "List ⌄" dropdown trigger next to the breadcrumb.
3. Observe: nothing happens (menu does not open).
4. (To get the menu open for step 5, use devtools console: document.querySelector('[id^="reka-dropdown-menu-trigger"]').click().)
5. With the menu open, click "Kanban".
6. Observe: item highlights on hover, but clicking it does not switch the view or close the menu.

Environment

• Frappe CRM, main/stable branch (frappe/erpnext v16.26.2-based deployment)
• Chrome: reproduced on Chromium 148 (headless, via Puppeteer) and stock Chrome (real user + CDP-simulated click via cloud browser)
• Firefox: not affected

Expected behavior

Clicking the view-switcher dropdown trigger opens the menu, and clicking a menu item switches the view, matching Firefox behavior.

[palamars]

Root cause found

Traced this down in frontend/src/components/ViewControls.vue, in the viewsDropdownOptions computed (around line 639):

const viewsDropdownOptions = computed(() => {
  ...
  if (list.value?.data?.views) {
    list.value.data.views.forEach((view) => {
      view.label = __(view.label)
      view.type = view.type || 'list'
      view.icon = getIcon(view.icon, view.type)   // new reference every recompute
      ...
      view.onClick = () => {...}                   // new reference every recompute
    })
    ...

This computed mutates the reactive objects it depends on (list.value.data.views, a reactive resource array) as a side effect, assigning fresh icon/onClick/label references on every recompute instead of returning derived copies.

Reproduced and instrumented the actual click gesture (real mouse click via CDP Input.dispatchMouseEvent, not synthetic .click()) with a MutationObserver + patched Event.prototype.preventDefault/stopPropagation:

• With the dropdown open and idle (no interaction), zero DOM mutations — so it's not a background loop.
• The instant a menu item receives pointerdown/focus, the item's DOM node gets unmounted+remounted repeatedly (~10 add/remove cycles observed in a single click).
• Sequence: pointerdown → focus lands on item → Reka UI's RovingFocusGroup (arrow-key nav) reacts to the focus change → triggers a re-render → viewsDropdownOptions recomputes → mutates icon/onClick with new references → Vue treats the item as changed identity → remounts its DOM node → freshly-mounted node has no focus → browser fires blur → RovingFocusGroup reacts again → repeat, until it settles a few ticks later.
• By the time mouseup fires, the element that received mousedown is no longer in the DOM (replaced by a later remount). Per the DOM/UI Events spec, Chrome does not dispatch the follow-up click event when the mousedown target has been removed before mouseup — so the item's onClick never runs. This also explains why the trigger button itself sometimes fails to open the menu when another Reka UI layer (e.g. a different open dropdown/dialog on the page) is simultaneously doing the same kind of focus churn.

This is Chrome-specific because Firefox apparently doesn't suppress the click in this same remount-during-gesture scenario.

Suggested fix

Don't mutate the source array in place inside the computed — return new derived objects instead:

const viewsFromData = list.value?.data?.views?.map((view) => ({
  ...view,
  label: __(view.label),
  type: view.type || 'list',
  icon: getIcon(view.icon, view.type),
  onClick: () => { ... },
})) || []

This breaks the self-referential mutation, so the computed becomes idempotent and won't force a remount of menu items just from being read during focus handling.

Happy to open a PR with this change if useful — let me know.

[palamars]

Follow-up with the actual fix, tested and shipped in our fork: palamars@bec2c343

Two contributing causes, both in the views dropdown (ViewControls.vue / ViewBreadcrumbs.vue):

1. viewsDropdownOptions (in ViewControls.vue) mutates the reactive list.value.data.views objects in place as a side effect on every recompute (view.label = __(view.label); view.onClick = () => {...}, etc.). This is the mutation-in-computed anti-pattern named in my earlier comment — fixed by deriving a new array via .map() instead of .forEach()-mutating the source.

2. Fixing (1) alone wasn't sufficient — real clicks on dropdown items still silently failed even for the fully static standardViews array (List/Kanban/Group By), which was never touched by the mutation in (1). Confirmed via a pinned-node check: tag the clicked element with a unique id, click it for real, then check element.isConnected immediately after — it comes back false, meaning the DOM node is detached by the time Chrome would dispatch the follow-up click. There's a second, not-fully-root-caused trigger for the same remount race (possibly Reka UI's RovingFocusGroup re-registering because the outer _views group-wrapper objects are still recreated fresh on every computed evaluation, even after the leaf view objects stopped mutating).

Rather than keep chasing (2), switched ViewBreadcrumbs.vue's per-item handler from @click="item.onClick" to @mouseup="() => { item.onClick(); close() }". Per the DOM/UI Events spec, Chrome only suppresses the derived synthetic click when the mousedown target gets detached before mouseup resolves — mouseup itself still dispatches normally regardless, so this sidesteps the race entirely without needing to find the second trigger. Had to add an explicit close() call since the dropdown's own click-to-close-on-select behavior was also silently relying on that same native click.

Verified both directions (List→Kanban and Kanban→List) with real (non-synthetic, CDP-dispatched) clicks — reliable across repeated attempts. Happy to open a PR with this if it's useful upstream.

[palamars]

Opened two PRs addressing pieces of this:

• fix: viewsDropdownOptions computed mutates its reactive source #2449 fixes the mutation-in-computed root cause described above (viewsDropdownOptions mutating list.value.data.views in place).
• fix: view menu (...) button unclickable/unstable due to zero-width hover reveal #2448 fixes a related but separate zero-width hover-reveal issue on the adjacent "..." context menu button in the same dropdown, found while investigating this one.

Note #2449 alone doesn't fully close this issue — after fixing the mutation, real clicks on dropdown items (including plain standardViews entries that were never part of the mutated array) still silently failed via the same detach-before-mouseup mechanism, confirmed via a pinned-node isConnected check. That second trigger isn't fully root-caused yet, so I didn't include the workaround I'm running on my own fork (@mouseup instead of @click, since Chrome still dispatches mouseup to the resolved target even when it suppresses the derived click) - happy to open that as a third PR too if it's useful, or if anyone has ideas on the actual second trigger.