Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Bug: WebKit crashes when drag-selecting text that auto-scrolls a diff (gutter-utility re-parented mid-drag)

Open
  • Is something wrong?
#1,184 4 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@OLavrik is already working on this.

Since Oct 10, 2026.

  • #1185 by @OLavrik — open

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
25/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
css, react, typescript
Domain
frontend

Research direction

Start with the FileDiff component's shadow-root styles, where the [data-code] element is set to display: grid, and with the line, gutter and content elements it contains. The reporter's table shows the crash depends on that grid on the scrolled element, so the first step is to reproduce it with Playwright WebKit using the spec they offer. Done means native selection with auto-scroll no longer crashes WebKit while the diff layout still holds, which likely needs a maintainer decision on the layout approach.

Written by the indexing model from the issue text.

Description

Prerequisites
  • I have searched for duplicate or closed issues
  • I have read the contributing guidelines
Describe the issue

On WebKit (Safari, and WKWebView hosts such as Tauri/Electrobun), drag-selecting text in a FileDiff until the selection reaches the viewport edge and the view auto-scrolls crashes the web-content process (Safari shows "A problem repeatedly occurred"; in a WKWebView the whole page reloads/dies). Chromium does not hard-crash. The WebKit assertion fires in EventHandler::handleMouseDraggedEvent.

Update (verified root cause). An earlier version of this issue blamed [data-code] being display: grid. A standalone, bisecting repro now disproves that. The real trigger is the gutter utility re-parenting a DOM node mid-drag, not the grid. Details below.

Root cause (verified with a standalone repro)

The crash requires enableGutterUtility: true (the review/comment gutter button — enabled in app review mode). With it on, InteractionManager repositions the utility button on every pointermove by moving a DOM node:

handlePointerMove → handlePointerEvent({move}) → placeUtility()
  → showUtilityOnLine(hoveredLine)
    → line.numberElement.appendChild(this.gutterUtilityContainer)

pointermove fires continuously during a native text-selection drag, so as the drag auto-scrolls and the hovered line changes, the utility <button> is re-parented into a different line-number cell on every move — a live DOM mutation under an in-progress native selection drag. That is what trips WebKit's handleMouseDraggedEvent assertion.

A/B matrix (standalone, pure additions, Desktop Safari / Playwright WebKit)
display:grid on scroll container enableGutterUtility gesture selection result
yes off drag to bottom edge 4 558 chars no crash
yes off drag to bottom-right corner (H+V autoscroll, long lines) 15 013 chars no crash
yes on drag to bottom edge — CRASH
no (grid moved to inner wrapper) off both gestures up to 15 013 chars no crash
no on both gestures — CRASH

So the crash correlates only with enableGutterUtility, not with display:grid on the scroll container. Native selection autoscroll (vertical and horizontal) over a display:grid scroll container does not crash on its own — even a 15k-char selection.

Why the old display:block bisection was misleading

Injecting [data-code]{ display:block !important } did stop the crash — but only because it collapses the entire grid layout, which degenerates the line-number cells the gutter utility appends into, so the mutation no longer runs. A proper structural fix that keeps the layout working (moving the grid to an inner [data-code-grid] wrapper and demoting [data-code] to display:block) was tried and still crashes with enableGutterUtility on. The display:block result was a layout-collapse side effect, not evidence that grid is the cause.

WebKit version sensitivity

The crash reproduces on webkit-2311 (Playwright 1.61 / recent Safari / Electrobun WKWebView) but not on webkit-2140 (Playwright 1.51). A WebKit e2e project pinned to 2140 will go green even though the bug is live, so any regression test must run on webkit 2311+.

Suggested fix (Diffs side)

Do not move/insert the gutter-utility node into line cells while a native text-selection drag is active:

  1. Gate hover-driven placeUtility() repositioning while a pointer button is down (an active native drag); restore placement on pointerup. (implemented in the linked PR)
  2. Or keep the utility node mounted in a single stable container and position it via CSS transform instead of appendChild-moving it between line elements.
Reproduction

Standalone repro (pure additions, @pierre/diffs): press inside the diff text with enableGutterUtility enabled, drag to the bottom edge and hold so selection autoscroll fires → the web-content process crashes on webkit 2311+. A Playwright spec is attached to the fix PR. Toggling enableGutterUtility off makes the identical gesture safe.

What browser(s) are you seeing the problem on?

Safari (WebKit), WKWebView (Tauri/Electrobun). Not Chrome.

Dominant language
TypeScript
Stars
6.2k
Forks
226
Avg merge
1d 11h
Merged PRs (30d)
34

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from pierrecomputer/pierre

All issues in pierrecomputer/pierre

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.