Keep oversized xwidgets visible with GNU-compatible geometry (#301)

[tag-und-nacht]

Summary

Closes #301. An xwidget wider than the room remaining in a row was produced, then removed by the body row's generic overflow rollback while its source character was still consumed. The result contained no FrameGlyph::Xwidget, so every backend correctly hid the view and showed only the buffer background.

GNU Emacs handles xwidgets specially in produce_xwidget_glyph: it may crop the glyph's layout advance to the remaining row width, while x_draw_xwidget_glyph_string keeps the native widget at its intrinsic size and clips its presentation to the window text area. Narrow mid-row xwidgets are left whole; display_line retains them in truncating rows and the presentation clip limits visibility.

Design

• DisplayXwidgetOverflowAction is xwidget-only. Images, videos, and shader surfaces retain their existing behavior; GNU's distinct image policy is not generalized here.
• XwidgetPresentationGeometry<Space> carries three separate concepts through layout, frame materialization, child-frame translation, rendering, native placement, and pointer hit-testing:
  • intrinsic XwidgetContentExtent;
  • typed XwidgetLayoutAdvance;
  • the visible clip in a branded coordinate space.
• WindowLocalRowExtent converts frame coordinates once, validates finite ordered geometry, and implements GNU's window-local quarter-width predicate. Invalid intervals cannot reach the crop policy.
• DisplayItemRightEdgeAdmission::PreserveWholeXwidget is the typed, exhaustive exception that permits only GNU's LeaveWhole xwidget case past the row boundary. Frame materialization preserves that whole advance instead of replacing it with the visible slice.
• Renderer composition and pointer dispatch resolve the same presentation geometry, preventing viewport, pixels, and hit targets from drifting apart.

WebView reliability found by the strict GUI test

The end-to-end test initially exposed two independent Linux backend defects that prevented reliable pixel verification:

• desired navigation/visibility state submitted while native creation was asynchronous was not reconciled before Ready;
• WPE pixel imports are borrowed, but Neomacs unreferenced the cached GBytes, causing use-after-free behavior on later callbacks.

The lifecycle now converges through typed pending/desired state, and the WPE boundary uses borrowed wrappers plus validated software pixel layouts. The incorrect unref is no longer available in the generated binding surface.

Tests

• Red-first layout regressions cover an oversized xwidget, a right-hand split, line-number-origin semantics, GNU's narrow LeaveWhole case, tall clipping, and invalid row geometry.
• Protocol/runtime/renderer tests cover content-vs-advance-vs-clip preservation, coordinate translation, composition, and hit-testing.
• A Linux real-GUI test loads a deterministic magenta data: page in an xwidget twice the live text-area size, asserts the semantic glyph geometry, and verifies actual pixels in the PNG. It passed 5 consecutive Wayland runs and 3 consecutive X11 runs.
• All 12 focused layout xwidget/geometry tests pass; all 52 neomacs-webview tests pass.

Known GNU gaps are documented next to the policy: zero-room glyphs, positive box-line widths, horizontal scrolling across first_visible_x, and GNU's ascent/descent split.

[tag-und-nacht]

GUI verification on the release build (cargo xtask fresh-build --release, then neomacs -Q -l oversize.el: xwidget-webkit-browse-url on example.com in a 502×442 px window, xwidget-resize, redisplay, neomacs--frame-snapshot nil 'json, and reading the window matrix):

state	xwidget-size-request	Xwidget glyph in the matrix	pixel_width	row height_px
fits	480×416	present	480	416
resized to 3× window height	502×1326	present (was absent before)	480	1326
resized to 2× window width	1004×442	present (was absent before)	480	442

The text area of that window is 480 px wide (502 minus fringes), so both resizes are width overflows and both are cropped to 480 exactly as GNU's crop = pixel_width - (last_visible_x - current_x) gives; the tall one keeps its 1326 px height and is clipped by the row's window clip. Before this change the same two snapshots had no Xwidget glyph at all.

[eval-exec]

I reviewed this against issue #301 and the separate GNU Emacs 31.0.90 image/xwidget paths in src/xdisp.c.

Blocking findings

1. Preserve intrinsic xwidget size separately from cropped layout width. cropped_to_visible_width overwrites DisplayMediaReplacement.width. That becomes the only width on FrameGlyph::Xwidget, and collect_frame_webviews then uses it as the native webview content rectangle. A 600px widget cropped to 304px therefore becomes a 304px browser viewport instead of a 600px viewport behind a 304px clip. GNU preserves the model/widget size and narrows only the glyph/visible region. Please model intrinsic content extent, layout advance extent, and visible clip extent separately.

2. Use window-local width in the GNU quarter-width predicate. for_replacement compares against right_edge_px / 4, but the caller supplies an absolute frame-space right edge. GNU last_visible_x is window-local. In a right-hand split, the inflated threshold can choose LeaveWhole, and the oversized xwidget can still be dropped. The policy should receive typed window-local available width/window width rather than an absolute coordinate. Please add a right-hand split regression.

3. Do not apply the xwidget rule generically to all media. builder.rs:1619-1636 applies one rule to images, videos, xwidgets, and surfaces. Issue #301 is specifically about xwidgets. GNU intentionally uses different policies:

   • image cropping accounts for word wrapping, line-number prefixes, margins, and box geometry;
   • xwidget cropping uses the simpler rule.

   With word-wrap, this PR can crop a mid-row image that GNU keeps whole so it can wrap. Video and surface behavior is also unrelated scope expansion.

4. The image slice arithmetic is incorrect when margins or box space exist. visible_width / self.width uses total glyph width, including horizontal margins/box expansion, to scale the source rectangle. GNU subtracts the cropped pixel count from the image slice after calculating total glyph width. A margined image therefore samples too much source and rescales it. The current test only covers zero margins.

There is also a documentation mix-up: the positive box-line-width paragraph is attached to cropped_to_visible_width rather than with_positive_box_line_width.

Recommended shape

For #301, narrow the immediate policy to DisplayMediaReplacementKind::Xwidget, preserve the intrinsic widget width, calculate cropping with window-local coordinates, and test both a right-hand split and the final native placement (content width = 600, visible width = 304). Image overflow should be a separate typed policy carrying wrap mode, line-number-prefix state, margins, and box geometry.

[tag-und-nacht]

Thanks for the review. Reworked in two commits on top of the original; the combined change is what to read.

1. Intrinsic size vs cropped width. New protocol type XwidgetContentExtent (GNU xw->width/xw->height) travels from DisplayMediaReplacementKind::Xwidget through GlyphType::Xwidget to FrameGlyph::Xwidget::content. The glyph's width stays the cropped slot (the cursor cell), clip_rect stays the text area, and collect_frame_webviews builds the placement from content ∩ clip, so the native view is 600 px behind a 304 px clip (a_cropped_xwidget_slot_keeps_the_native_content_width_behind_the_clip asserts content_rect().width() == 600, visible_rect().width() == 304). The pointer hit test reads the same pair. The row hash mixes the extent in.

2. Window-local width. DisplayRowTextAreaOrigin (text-area left edge = content x minus the line-number prefix, per it->current_x counting the prefix) rides with DisplayRowRenderBounds from the append context to the row writer, and WindowLocalRowExtent converts once before the rule runs. Right-hand split regressions: the_quarter_width_rule_uses_the_windows_own_width_in_a_right_hand_split (policy) and layout_frame_rust_crops_an_xwidget_in_a_right_hand_split_by_the_windows_width (engine: 300 px widget at frame x 1368 in the right window of a 1600 px frame; cropped to 224 with the window-local origin, dropped with the frame-absolute one). A second engine test checks the origin with display-line-numbers on: a 195 px widget after the prefix is left whole (≤ 784/4), a 200 px one is cropped.

3. Xwidgets only. The policy is now DisplayXwidgetOverflowAction, matched on DisplayMediaReplacementKind::Xwidget in the pattern; images, videos and surfaces are back to the previous behavior, and the image rule (xdisp.c:32457-32473) is left for its own typed policy.

4. Image slice arithmetic. Removed along with the image path.

Doc mix-up. The paragraph is back on with_positive_box_line_width.

Ledger of what is still not GNU (in the enum's doc): LeaveWhole drops the glyph where display_line would continue/truncate it (the pre-existing behavior, now limited to widgets GNU also leaves whole); the hpos == 0 no-room case is dropped rather than produced at zero width (:32600); box line widths are not added before the crop (:32556-32570); hscroll's first_visible_x is not carried (:3507).

Not run here: the Linux wgpu draw paths (draw_inline_webkit_views, render_frame_content) now draw the content extent cut to the clip through clipped_media_rect, the image branch's helper; they are compiled only on Linux. Everything else was run on macOS. A GUI probe of a 600 px widget after 70 cells in a right-hand split shows content width 600 with a 206 px advance, the exact text-area remainder.

[tag-und-nacht]

Rebased onto current main (5195028) after GitHub flagged the conflict. What changed beyond the rebase itself, so nothing lands here silently:

• Dropped test(layout-engine): gate the Fontconfig font test to Linux. Your 2808417 made the same change, so that commit was skipped rather than merged.
• ce42d8f refactor(layout): define the text-area left edge once. Your 1382937 added DisplayRowAppendSurface::text_area_left for hscroll truncation. It computes the same edge (content_x - line_number_width) that this branch's DisplayRowAppendFrame::text_area_origin computed on its own for the window-local it->current_x extent (src/dispextern.h:2785-2791). The textual merge kept both, so DisplayRowAppendArea::text_area_left is now the one definition: the surface delegates to it and the frame holds the area instead of three copied fields.
• 077f58d fix(display-protocol): validate an xwidget content extent on deserialization too. The derived Deserialize bypassed XwidgetContentExtent::new, so a serialized frame could carry a zero or non-finite extent the constructor refuses. It now deserializes through #[serde(try_from)]; same wire shape, red-first test on {"width_px":0.0,…}.
• 67f5af1 docs(layout): declare the remaining gaps. Three things produce_xwidget_glyph does that the ledger did not list: a widget straddling first_visible_x under hscroll (this port's skip phase consumes it before the rule runs), it->hpos == 0 counting only visible glyphs (src/xdisp.c:25705-25706), and the even ascent/descent split (:32546-32547). Two citations were off by a line or pointed at the continuation test instead of the restore branch; corrected to 32557-32571 and 26221-26224 / 26416-26434.

Checked for semantic drift, not just merge cleanliness: of the 108 upstream commits since the previous base, 15 touch this branch's files; 1382937 was the only real overlap (above). Its skip phase never carries a media replacement, so it cannot reach the RejectOverflowingGlyph crop arm.

Run on macOS: cargo fmt --check; cargo clippy --all-targets on display-protocol, layout-engine, display-runtime and renderer-wgpu (the latter two with webview); the four crates' test suites. On this machine main itself fails 26 tests in display-protocol/layout-engine (font-cluster shaping after the freetype removal, the gui_chrome Lisp loads, and glyph_pointer_token_has_small_niche_sized_overhead: Glyph is 104 bytes on main, the bound is 80; GlyphType is sized by AutomaticComposite, so the 8-byte XwidgetContentExtent on the Xwidget variant does not move it). This branch fails exactly that set and nothing else. Not run: the Linux wgpu paths and the WPE build.

Left as-is, for the record: the policy seam (for_xwidget, xwidget_advance_cropped_to) still takes bare f32 rather than Px; the pointer hit test's new test sits in the existing inline mod webview_tests; body_render.rs has its own text_area_left from text_x, equal by construction (content_x = text_x + line_number_pixel_width).