react-x11 2.47.3 → 2.47.5

package/src/components/Dialog.js

@@ -4,15 +4,13 @@
 
 import React, { useEffect, useLayoutEffect, useRef, useState } from 'react';
 import { capTrim, labelContent, useTheme } from './theme.js';
-import { centerRect } from './anchor.js';
+import { windowRect } from '../anchor.js';
 import { XK_ESCAPE } from './keys.js';
 
 const h = React.createElement;
 
 const DEFAULT_WIDTH = 360;
 
-const DEFAULT_HEIGHT = 170;
-
 /**
  * <Dialog open title onClose actions>…</Dialog> — a dialog in a `<popup>`,
  * centred over the owner window.
@@ -58,13 +56,36 @@ const DEFAULT_HEIGHT = 170;
  * belongs to the `states` work; it means nothing without the
  * `WM_TRANSIENT_FOR` this now sets, which is why that had to come first.
  *
- * `width`/`height` are explicit rather than sized to content, and now only
- * because of where the dialog is *placed*: `centeredRect` needs the size to
- * work out the offset that centres it over its owner, and that is computed
- * during the render that opens the popup, before anything has been laid out.
- * The popup itself could size to its content — see "Natural size" in
- * docs/elements.md — so this is the anchor math's constraint, not the X
- * window's.
+ * **The height is the content's** (issue #940). It used to be 170 whatever
+ * the dialog held, because the dialog was centred from React — and centring
+ * needs a size, which React does not have before anything is laid out. So
+ * content past 170 was laid out below the bottom of the window and cut off
+ * there, `actions` first: the one row a dialog cannot do without was the
+ * first to go. Now the popup centres *itself*: `anchor={{ rect, placement:
+ * 'center' }}` over its owner window, and `realize()` measures the content,
+ * places it from that size and only then creates the window — so it is born
+ * the right size in the right place, the order an anchored menu already
+ * had. `height="auto"` is the default because a fixed height that clips is
+ * never what anyone means; a number is still exactly that number.
+ *
+ * Three things follow from it:
+ *
+ * - **Capped at the monitor**, as every `'auto'` window is. Past that the
+ *   body scrolls (`overflow: 'scroll'`, a tab stop only while it does) and
+ *   the actions row stays pinned under it, in the window — under a fixed
+ *   height too, which used to clip the same way.
+ * - **It follows its content** while open (the `'auto'` re-fit, #929), and
+ *   grows from where it is rather than being centred again: its top edge
+ *   stays put, so a line appearing under a field does not move the field
+ *   under the pointer. It is pulled up only as far as it takes to stay on
+ *   the monitor (`_keepCentredTop`, nodes/window/anchoring.js).
+ * - **It is centred once**, over where the owner was when it opened — the
+ *   owner's rect is taken when the dialog opens and is not tracked after,
+ *   so a managed dialog the user dragged aside stays where they put it.
+ *
+ * `width` stays a number by default (360): a body of prose wraps to it, and
+ * a natural width would be as wide as its longest sentence. `width="auto"`
+ * is there for a dialog whose content is laid out to its own width.
  */
 export function Dialog({
   open,
@@ -74,35 +95,38 @@ export function Dialog({
   actions,
   managed = true,
   width = DEFAULT_WIDTH,
-  height = DEFAULT_HEIGHT,
+  height = 'auto',
   style,
   ...boxProps
 }) {
   const theme = useTheme();
   const anchor = useRef(null);
   const surface = useRef(null);
-  const [rect, setRect] = useState(null);
+  // the owner window's rect on the screen, which the popup centres itself
+  // over — taken once, when the dialog opens (see above)
+  const [owner, setOwner] = useState(null);
 
-  // the popup needs screen coordinates, which are only knowable once the
-  // anchor is laid out inside a realized window — hence a layout effect
-  // rather than placement at render time
+  // Screen coordinates are only knowable once the anchor is laid out inside
+  // a realized window — hence a layout effect rather than placement at
+  // render time. The size is not needed here any more: the popup works out
+  // its own, and its own position from it.
   useLayoutEffect(() => {
     if (!open) {
-      setRect(null);
+      setOwner(null);
       return;
     }
-    const next = centerRect(anchor.current, { width, height });
-    if (next) setRect(next);
-  }, [open, width, height]);
+    const next = windowRect(anchor.current);
+    if (next) setOwner(next);
+  }, [open]);
 
   // nothing inside claimed focus (no autoFocus): the dialog takes it itself,
   // the way a browser focuses a <dialog> element, so keys have somewhere to
   // land and the trap has an inside
   useEffect(() => {
     const node = surface.current;
-    if (!rect || !node || node.focusWithin) return;
+    if (!owner || !node || node.focusWithin) return;
     node.focus();
-  }, [rect]);
+  }, [owner]);
 
   const onKeyDown = (ev) => {
     if (ev.keysym === XK_ESCAPE) {
@@ -119,14 +143,13 @@ export function Dialog({
       ref: anchor,
       style: { position: 'absolute', width: 0, height: 0 },
     },
-    rect &&
+    owner &&
       h(
         'popup',
         {
-          x: rect.x,
-          y: rect.y,
-          width: rect.width,
-          height: rect.height,
+          anchor: { rect: owner, placement: 'center' },
+          width,
+          height,
           trapFocus: true,
           // A managed window is the window manager's to move, and a
           // client-side pointer grab over one is a fight nobody wins — the
@@ -181,10 +204,28 @@ export function Dialog({
               },
               title,
             ),
+          // The body is what gives way when the dialog cannot be as tall as
+          // its content — capped at the monitor, or held to a `height` — so
+          // it scrolls, and the actions row below it never leaves the window.
+          //
+          // The column inside it is `height: '100%'` rather than its natural
+          // height, which is what keeps the body's old behaviour for content
+          // that fills it: inside a scroller a box is as tall as its content,
+          // and a dialog built as a field over a list that scrolls on its own
+          // (the chat example's) would have its list laid out whole and the
+          // body scrolled instead. At the viewport's height that content is
+          // squeezed as it always was, and content that cannot be squeezed
+          // that far — lines of text — is held at its automatic minimum
+          // (#249), which is taller than the viewport, and that is the
+          // overflow the body scrolls.
           h(
             'box',
-            { style: { flexGrow: 1, gap: 8 } },
-            labelContent(children, { color: theme.text }),
+            { style: { flexGrow: 1, overflow: 'scroll' } },
+            h(
+              'box',
+              { style: { gap: 8, height: '100%' } },
+              labelContent(children, { color: theme.text }),
+            ),
           ),
           actions &&
             h(

package/src/components/Menu.js

@@ -2,7 +2,13 @@
 // support needed. Plain createElement (no JSX) so the library stays
 // build-step-free for consumers.
 
-import React, { useEffect, useMemo, useRef, useState } from 'react';
+import React, {
+  useEffect,
+  useLayoutEffect,
+  useMemo,
+  useRef,
+  useState,
+} from 'react';
 import {
   capBand,
   capTrim,
@@ -990,14 +996,45 @@ export function ContextMenu({
   ...boxProps
 }) {
   const ref = useRef(null);
-  const [rect, setRect] = useState(null);
+  // Where the right-click asked for the menu, in logical root coordinates —
+  // and nothing else. What to show, and so how big a popup and where it can
+  // fit, is decided from the `items` of the render the menu appears in.
+  //
+  // The click cannot decide it: a row inside here says which thing was
+  // right-clicked in its own `onContextMenu`, which runs before ours on the
+  // same event but renders after it, and an app derives the items from that.
+  // Read at the click, the items were the render before's — so a menu with
+  // none before opened on the second right-click, and one that grew showed
+  // its new rows in a popup sized for the old ones (#934).
+  const [anchor, setAnchor] = useState(null);
   const [path, setPath] = useState([]);
   const typeAhead = useTypeAhead();
   const rtl = useDirection() === 'rtl';
   const metrics = useMenuMetrics(fontSize);
 
+  const showing = anchor != null && visibleItems(items).length > 0;
+  const rect = useMemo(() => {
+    const node = ref.current;
+    if (!showing || !node) return null;
+    const width = menuListWidth(node, items, metrics);
+    const height = menuListHeight(items, metrics);
+    const area = anchorArea(node);
+    // anchored at the pointer rather than at a widget: clamp by hand, since
+    // there is no anchor rect to flip around
+    return {
+      x: area
+        ? Math.max(area.x, Math.min(anchor.x, area.x + area.width - width))
+        : anchor.x,
+      y: area
+        ? Math.max(area.y, Math.min(anchor.y, area.y + area.height - height))
+        : anchor.y,
+      width,
+      height,
+    };
+  }, [showing, anchor, items, metrics]);
+
   const close = () => {
-    setRect(null);
+    setAnchor(null);
     setPath([]);
   };
   const select = (item) => {
@@ -1016,30 +1053,34 @@ export function ContextMenu({
   // pointer grab until something closes it
   useDismissOnWindowBlur(ref, Boolean(rect), close);
 
+  // Settled in the commit the click's own updates land in, before anything
+  // is drawn. Nothing to show is no menu at all — no popup, so no grab, and
+  // the focus left where the press put it — and the request is dropped
+  // rather than kept, or items arriving later would open a menu nobody
+  // asked for just then. The same goes for items emptied under an open menu.
+  useLayoutEffect(() => {
+    if (!anchor) return;
+    if (!showing) {
+      close();
+      return;
+    }
+    // `'pointer'`, so no ring: this only ever opens from a right-click, and
+    // the wrapper is the whole content area — a focus ring around all of it
+    // says nothing a keyboard user needs and quite a lot nobody wants.
+    const node = ref.current;
+    node?.root?.events?.focus?.(node, 'pointer');
+  }, [anchor, showing]);
+
   const openAt = (ev) => {
     const node = ref.current;
-    if (!node || !items.length) return;
-    const width = menuListWidth(node, items, metrics);
-    const height = menuListHeight(items, metrics);
-    const area = anchorArea(node);
-    // anchored at the pointer rather than at a widget: clamp by hand, since
-    // there is no anchor rect to flip around. Root coordinates are device;
-    // the rect feeds popup props, which are logical like the area.
-    const x = (ev.nativeEvent?.rootx ?? ev.x * node.scale) / node.scale;
-    const y = (ev.nativeEvent?.rooty ?? ev.y * node.scale) / node.scale;
-    setRect({
-      x: area ? Math.max(area.x, Math.min(x, area.x + area.width - width)) : x,
-      y: area
-        ? Math.max(area.y, Math.min(y, area.y + area.height - height))
-        : y,
-      width,
-      height,
+    if (!node) return;
+    // Root coordinates are device; the anchor feeds popup props, which are
+    // logical like the area they are clamped to.
+    setAnchor({
+      x: (ev.nativeEvent?.rootx ?? ev.x * node.scale) / node.scale,
+      y: (ev.nativeEvent?.rooty ?? ev.y * node.scale) / node.scale,
     });
     setPath([-1]);
-    // `'pointer'`, so no ring: this only ever opens from a right-click, and
-    // the wrapper is the whole content area — a focus ring around all of it
-    // says nothing a keyboard user needs and quite a lot nobody wants.
-    node.root?.events?.focus?.(node, 'pointer');
   };
 
   return h(

package/src/events.js

@@ -424,7 +424,10 @@ export class EventManager {
     // windows' focus events settle it once rather than twice
     // (`_syncDefaultFocus`)
     this._defaultFocusOn = false;
-    this._lastClick = { time: 0, x: 0, y: 0, detail: 0 };
+    // the last press, which the next is counted against (`_clickDetail`).
+    // No time until there has been one: a 0 here made the first press on a
+    // server up for less than the double-click window count as a second.
+    this._lastClick = { time: null, stamped: false, x: 0, y: 0, detail: 0 };
     // the sub-pixel part of a smooth scroll the default action has not spent
     // yet — see `_onWheel`, which moves whole pixels so the scroll blit stays
     // available
@@ -567,9 +570,19 @@ export class EventManager {
    * and `Net/DoubleClickDistance` — falling back to 400ms/4px where no
    * settings daemon answered. A double click that needs to be faster here
    * than everywhere else on the desktop is a double click people miss.
+   *
+   * The time is the press's own, which is when the user pressed. When it was
+   * handled is another matter: a first click whose render outlasts the
+   * window holds the second press back past it, and a double click read off
+   * the clock came out as two singles (#936). The X server stamps a press
+   * in milliseconds, and so do AppKit (its uptime) and a Wayland
+   * compositor. A press that carries no time (win32's, a test's `emit`) is
+   * timed by the clock instead, and never against one that carried its own:
+   * the two count from nothing in common.
    */
   _clickDetail(native) {
-    const now = Date.now();
+    const stamped = typeof native.time === 'number';
+    const now = stamped ? native.time : Date.now();
     const last = this._lastClick;
     const { doubleClickMs, doubleClickDistance } = desktopSettings(
       this.node?.app,
@@ -577,12 +590,17 @@ export class EventManager {
     // the desktop's slop is logical pixels; the coordinates are device
     const slop = doubleClickDistance * this.scale;
     const detail =
-      now - last.time < doubleClickMs &&
+      last.time !== null &&
+      last.stamped === stamped &&
+      // X time is 32 bits and wraps every 49.7 days: unsigned, a press just
+      // past the wrap is still just after the one before it, and one stamped
+      // earlier than the last is never inside the window
+      (now - last.time) >>> 0 < doubleClickMs &&
       Math.abs(native.x - last.x) <= slop &&
       Math.abs(native.y - last.y) <= slop
         ? last.detail + 1
         : 1;
-    this._lastClick = { time: now, x: native.x, y: native.y, detail };
+    this._lastClick = { time: now, stamped, x: native.x, y: native.y, detail };
     return detail;
   }
 

package/src/frame/index.js

@@ -706,7 +706,10 @@ function PaneHostView({
       // reached the pane with none: Shift+Tab went forwards there, and a
       // Ctrl+C or a Shift+click was a C and a click.
       buttons: ev.nativeEvent?.buttons ?? 0,
-      time: Date.now(),
+      // And the time the input carried, which the pane counts a double
+      // click by: stamped as the host got round to sending it, a first click
+      // the host was slow to answer put the second outside the window (#936)
+      time: ev.nativeEvent?.time ?? Date.now(),
       ...data(ev),
     };
     try {

package/src/idle.js

@@ -31,6 +31,16 @@
 // next check is 288 seconds away — so an active user costs one round trip per
 // timeout period.
 //
+// A backend with no X server says the same number itself, as
+// `app.lastInputMs()`: `GetLastInputInfo` on win32, and on macOS the bridge's
+// CoreGraphics read or `ioreg`'s `HIDIdleTime` (src/cocoa/idle.js). That rung
+// polls on the same schedule, and may answer with a promise.
+//
+// Every rung stops when the last subscriber to its timeout goes. A watcher
+// that outlived its component kept its alarm, or its poll, for the life of
+// the root — near free for an alarm, and a child process per check for
+// `ioreg`.
+//
 // ## Inhibition: three rungs that agree on what they do
 //
 // All three keep the **screen** awake and none of them stops a suspend. That
@@ -187,11 +197,12 @@ class IdleWatcher {
 async function armIdle(watcher) {
   const session = watcher.session;
 
-  // The Windows rung, first because it is the only one there: everything
-  // below this reaches into `app.X`, and a tree that is not on an X server
-  // has none. `GetLastInputInfo` answers for the whole session, which is what
-  // an idle timeout means, so the shape is the polling rung's — with the
-  // answer arriving synchronously instead of over a connection.
+  // The rung for a backend with no X server, first because it is the only
+  // one there: everything below this reaches into `app.X`, and the cocoa and
+  // win32 apps carry at most a stub of one. `GetLastInputInfo` and macOS's
+  // idle time both answer for the whole session, which is what an idle
+  // timeout means, so the shape is the polling rung's — with the answer
+  // coming from a call, or from a child process, instead of a connection.
   if (typeof session.app?.lastInputMs === 'function') {
     pollLastInput(watcher);
     return;
@@ -293,27 +304,37 @@ function poll(watcher, saver) {
 }
 
 /**
- * The same adaptive wait as {@link poll}, over a counter this process can read
- * without asking anybody: `GetLastInputInfo` is a call, not a round trip.
+ * The same adaptive wait as {@link poll}, over a number the backend reads
+ * itself: `GetLastInputInfo` is a call, not a round trip, and so is the cocoa
+ * bridge's; the cocoa `ioreg` fallback is a child process, and answers with a
+ * promise.
  *
  * The two directions are still asymmetric for the same reason. Not idle yet:
  * sleep for exactly the remainder. Idle: nothing says when the user will come
  * back, and no input reaches this process while they are typing in another
- * window, so poll on an interval scaled to the timeout.
+ * window, so poll on an interval scaled to the timeout. No answer at all —
+ * `ioreg` failed — asks again a timeout later, the way {@link poll} does on
+ * an error, rather than settling on "not idle" for good.
  */
-function pollLastInput(watcher) {
+async function pollLastInput(watcher) {
   if (watcher.stopped) return;
-  const elapsed = watcher.session.app.lastInputMs?.();
-  if (typeof elapsed !== 'number') return;
-  const idle = elapsed >= watcher.timeout;
-  watcher.set(idle);
-  clearTimeout(watcher._timer);
-  watcher._timer = setTimeout(
-    () => pollLastInput(watcher),
-    idle
+  let elapsed = null;
+  try {
+    elapsed = await watcher.session.app.lastInputMs();
+  } catch {
+    // no answer this time; asked again below
+  }
+  if (watcher.stopped) return;
+  let wait = watcher.timeout;
+  if (Number.isFinite(elapsed)) {
+    const idle = elapsed >= watcher.timeout;
+    watcher.set(idle);
+    wait = idle
       ? Math.min(30_000, Math.max(1_000, watcher.timeout / 4))
-      : Math.max(250, watcher.timeout - elapsed),
-  );
+      : Math.max(250, watcher.timeout - elapsed);
+  }
+  clearTimeout(watcher._timer);
+  watcher._timer = setTimeout(() => pollLastInput(watcher), wait);
   watcher._timer.unref?.();
 }
 
@@ -347,7 +368,16 @@ export function watchIdle(app, timeout, onChange) {
     });
   }
   watcher.listeners.add(onChange);
-  return () => watcher.listeners.delete(onChange);
+  return () => {
+    watcher.listeners.delete(onChange);
+    if (watcher.listeners.size > 0 || watcher.stopped) return;
+    // The last one out stops the alarm or the poll; the next subscriber to
+    // this timeout arms a new watcher.
+    watcher.stop();
+    if (session.watchers.get(timeout) === watcher) {
+      session.watchers.delete(timeout);
+    }
+  };
 }
 
 /** Tear down with the root that started it. */

package/src/idlehooks.js

@@ -30,8 +30,11 @@ import { idleSnapshot, keepAwake, watchIdle } from './idle.js';
  * **no timer at all**: a SYNC alarm fires when the counter crosses `timeout`
  * and again when input pulls it back down. On a server without one (XQuartz)
  * it falls back to polling MIT-SCREEN-SAVER, scheduled against the remaining
- * time rather than on a tick. On a display with neither it stays `false`,
- * which is the honest answer for a display that cannot be asked.
+ * time rather than on a tick. win32 and macOS answer the same number
+ * themselves (`GetLastInputInfo`; the bridge's CoreGraphics read, or `ioreg`
+ * under a bridge without one) and are polled on that schedule. On an X
+ * display with neither extension it stays `false`, which is the honest
+ * answer for a display that cannot be asked.
  *
  * `timeout` is a dependency: passing a computed value re-arms on every change,
  * so hold it in a constant or a `useMemo` rather than building it inline from

package/src/index.d.ts

@@ -135,11 +135,16 @@ export interface ClipboardOptions {
 export interface SelectionChange {
   selection: string;
   /** Window now owning it, or `0` when nothing does — the case an edit
-   * menu wants. */
+   * menu wants. On the Cocoa backend no window owns the pasteboard: `-1`
+   * when it holds anything, `0` when it was left empty. */
   owner: number;
   timestamp?: number;
   selectionTimestamp?: number;
   reason?: 'new-owner' | 'destroyed' | 'closed';
+  /** Cocoa only: `NSPasteboard.changeCount` after the change, which every
+   * write bumps — what a clipboard history tells one copy from the next
+   * by. */
+  changeCount?: number;
 }
 
 /** What `useClipboard()` returns. See docs/clipboard.md. */
@@ -152,7 +157,10 @@ export interface Clipboard {
   writeText(text: string, options?: ClipboardOptions): Promise<void>;
   /** Stop owning the selection, so nothing is served for it any more. */
   clear(selection?: string): Promise<void>;
-  /** What the current owner can convert to; `[]` when nothing owns it. */
+  /** What the current owner can convert to; `[]` when nothing owns it.
+   * On the Cocoa backend, the pasteboard's types: MIME names where there is
+   * one (`image/png`), text as both its X and MIME names, and any other
+   * type under its own identifier (`org.nspasteboard.ConcealedType`). */
   targets(options?: ClipboardOptions): Promise<string[]>;
   /** Plain text, via the owner's `UTF8_STRING`/`STRING` targets. Rejects
    * when there is no owner or it offers neither — `read('text')` is the
@@ -169,7 +177,10 @@ export interface Clipboard {
     options?: ClipboardOptions,
   ): Promise<Array<{ uri: string; path?: string }>>;
   /** Called whenever the selection changes hands. Resolves to an
-   * unsubscribe function. Rejects on a server without XFixes. */
+   * unsubscribe function. Rejects on a server without XFixes. On the Cocoa
+   * backend it is the pasteboard's change count, asked four times a second
+   * while something is watching: copies closer together than that are one
+   * change. */
   watch(handler: (change: SelectionChange) => void): Promise<() => void>;
   watch(
     selection: string,

package/src/nodes/node.js

@@ -1033,6 +1033,12 @@ export class Node {
     // point. A key an open composition took reaches no default action at all.
     const space = ev.keysym === XK_SPACE || ev.codepoint === 32;
     if (!enter && !space) return;
+    // …unmodified, or with Shift alone. Ctrl, Alt or Super make the key a
+    // chord, which is a command and somebody else's — a menu's Ctrl+Return,
+    // ⌘↩ on the Cocoa backend — and a press here would consume it on the way
+    // past (#935). Shift is not a command: it reaches `onClick` as a
+    // shift-click, the way GTK's `activate` takes it too.
+    if (ev.ctrlKey || ev.altKey || ev.metaKey) return;
     if (!hasClickHandler(this)) return;
     // consumed, said the way every default action says it: what it prevents
     // is the default action after this one

package/src/nodes/textarea.js

@@ -10,6 +10,7 @@ import {
   XK_PAGE_UP,
   XK_PAGE_DOWN,
   XK_END,
+  primaryModifier,
   primaryModifierHeld,
 } from '../keysyms.js';
 import {
@@ -310,11 +311,19 @@ export class TextAreaNode extends TextInputNode {
     const layout = this._valueLayout();
 
     if (k === XK_RETURN || k === XK_KP_ENTER) {
-      // Ctrl+Enter, ⌘↩ on the Cocoa backend
+      // Ctrl+Enter, ⌘↩ on the Cocoa backend — the field's submit when it has
+      // an `onSubmit`, and with none a chord it has no answer for, which goes
+      // on to a shortcut the way it does from a <textinput> (#935)
       if (primaryModifierHeld(ev, this.app)) {
+        if (!this.props.onSubmit) return false;
         this._fireValueEvent('onSubmit', this.value, ev.nativeEvent);
         return true;
       }
+      // Alt+Return and Super+Return are chords too, and a field types
+      // nothing for a chord — except on the Mac, where ⌃↩ and ⌥↩ are
+      // AppKit's own newline bindings and its shortcuts are ⌘ chords anyway
+      const mac = primaryModifier(this.app) === 'Super';
+      if (!mac && (ev.altKey || ev.metaKey)) return false;
       this._goalX = null;
       this._insert('\n');
       return true;

package/src/nodes/textinput.js

@@ -506,6 +506,14 @@ export class TextInputNode extends Node {
     const k = ev.keysym;
 
     if (k === XK_RETURN || k === XK_KP_ENTER) {
+      // Return submits, and Shift+Return with it — Shift is not a command.
+      // Ctrl, Alt or Super make it a chord, and a chord this field has no
+      // answer for is not the field's (below): a menu's Ctrl+Return, ⌘↩ on
+      // the Cocoa backend, reaches the menu (#935). Nor is a Return nobody
+      // listens for — with no `onSubmit` there is no answer to give, and the
+      // key goes on to a shortcut that wants it, a form's default button.
+      if (ev.ctrlKey || ev.altKey || ev.metaKey) return false;
+      if (!this.props.onSubmit) return false;
       this._fireValueEvent('onSubmit', this.value, ev.nativeEvent);
       return true;
     }