experiments in a post-browser web
fix(page): handle webview mousemove during active drag for window movement
The drag overlay's pointer-events:all may not reliably intercept mouse
events from the webview's compositor surface. When the webview guest
continues sending __PEEK_MOUSEMOVE__ messages during an active drag,
they were being discarded by the early return (if !webviewHoldTimer).
Now when isDragging is true, webview mousemove messages update the
window position using the same delta calculation as the document-level
mousemove handler. This ensures drag works regardless of whether the
overlay or the webview captures the mouse events.
+15
-2
+15
-2
app/page/page.js
+15
-2
app/page/page.js
···
446
446
return;
447
447
}
448
448
449
-
// --- Mousemove from webview: cancel hold if moved too far ---
449
+
// --- Mousemove from webview: update drag or cancel hold ---
450
450
if (e.message.startsWith('__PEEK_MOUSEMOVE__:')) {
451
-
if (!webviewHoldTimer) return; // No pending hold
452
451
const parts = e.message.split(':');
453
452
const screenX = parseFloat(parts[1]);
454
453
const screenY = parseFloat(parts[2]);
455
454
if (isNaN(screenX) || isNaN(screenY)) return;
455
+
456
+
// If actively dragging, update window position from webview mouse coords.
457
+
// The drag overlay may not capture events from the webview's compositor
458
+
// surface, so we must handle drag movement here as well.
459
+
if (isDragging) {
460
+
const dx = screenX - dragStartScreenX;
461
+
const dy = screenY - dragStartScreenY;
462
+
screenBounds.x = dragStartBoundsX + dx;
463
+
screenBounds.y = dragStartBoundsY + dy;
464
+
setWindowBounds(computeWindowBounds(screenBounds));
465
+
return;
466
+
}
467
+
468
+
if (!webviewHoldTimer) return; // No pending hold
456
469
const dx = Math.abs(screenX - webviewHoldScreenX);
457
470
const dy = Math.abs(screenY - webviewHoldScreenY);
458
471
if (dx > 5 || dy > 5) {