[macOS/X11] Rebuilding and reusing TGPopupMenu makes context menus block in XGetGeometry

[dsavran]

Check duplicate issues.

• Checked for duplicates

Description

On macOS with the X11 backend, the first context menu in a newly created
TCanvas or TBrowser appears immediately, but subsequent right-clicks in the same window are delayed by several seconds. During the delay, all ROOT GUI windows stop responding.

The behavior can be reproduced with TGPopupMenu alone, without TCanvas, TBrowser, TContextMenu, object selection or ROOT reflection. A static menu and a freshly created menu remain fast. The delay starts when the same TGPopupMenu instance is dynamically rebuilt and reused for a second time.

The menu rebuild itself takes less than 0.1 ms. The next synchronous geometry request blocks in approximately 520 ms increments, with the total delay increasing with the number of menu entries.

Expected behavior

Every context menu should appear immediately, as the first one does. Rebuilding and reusing a TGPopupMenu should not make the following X11 geometry request block for hundreds of milliseconds or several seconds.

Reproducer

Save the attached minimal_tgpopupmenu_reproducer.C and run:

root -l minimal_tgpopupmenu_reproducer.C

Then:

1. Right-click repeatedly in the white window.
2. Close each popup by selecting one of its entries.
3. Compare the printed rebuild and PlaceMenu times.

On the affected system the first popup is fast. Subsequent popups are delayed, typically by about 0.52 or 1.04 seconds for this eight-entry example, while rebuild remains below 0.1 ms.

A normal TCanvas shows the user-visible issue directly:

auto c = new TCanvas("c", "c", 900, 650);
c->DrawFrame(0., 0., 1., 1.);

The first context menu is immediate. Subsequent context menus take about
2.5 seconds for a 19-entry TFrame menu and about 5 seconds for larger
TAxis or TCanvas menus.

minimal_tgpopupmenu_reproducer.C

ROOT version

%60%60%60%0AROOT v6.40.02%0ABuilt for macosxarm64 on Jun 11 2026, 10:20:29%0AFrom tags%2F6-40-02@6-40-02%0AWith Apple clang version 21.0.0 (clang-2100.1.1.101) std201703%0ABinary directory: %2Fopt%2Flocal%2Flibexec%2Froot6%2Fbin%0A%60%60%60

Installation method

MacPorts, build from source

Operating system

macOS 26.6 (25G72), Apple Silicon arm64

Additional context

Instrumenting the real canvas path shows that almost the complete delay occurs before TGPopupMenu::PlaceMenu():

before PlaceMenu=2075.299 ms, PlaceMenu=5.893 ms
before PlaceMenu=2577.256 ms, PlaceMenu=5.367 ms

A focused Xlib trace matches those measurements to one XGetGeometry() call from TRootContextMenu::DisplayPopup() on the canvas/container window:

XGetGeometry drawable=0x60006e duration=2074.469 ms
XGetGeometry drawable=0x60006e duration=2576.016 ms

The same request on the first click took about 0.260 ms. ROOT waits in
_XReply -> xcb_wait_for_reply64 -> poll. A simultaneous XQuartz process sample shows X11.bin blocked in an AppKit/CoreAnimation transaction. A pure Xlib control program using reusable override-redirect windows, resize, map/unmap and pointer grabs remains fast.

Static menus remain fast. Fresh popup instances rebuilt once remain fast. The delay requires rebuilding and displaying the same popup instance more than once. No matching existing ROOT or XQuartz issue was found in searches for TGPopupMenu, XGetGeometry, XQuartz and delayed context menus.

The issue was not present on the previous installation. That installation used ROOT 6.38.04 with the X11 variant and the same MacPorts libX11/libxcb versions, but a different macOS installation state.

Detailed results and optional process samples are included in the attachment

root-bug-report-attachments.zip

package.