[Problem/Bug]: Mouse drag input starves main thread of IPC/WebSocket/Worker messages when FPS is uncapped

What happened?

What happened?

When --disable-frame-rate-limit is passed as an additional browser argument, dragging the mouse with the left button held causes the Blink main thread scheduler to excessively prioritize mouse input events, starving IPC messages, WebSockets, and Web Workers of processing time for extended periods. This manifests as severe latency spikes in any messaging that relies on the main thread — in a game context, this causes what's commonly known as "aim freeze": the mouse visually moves but game state (communicated via WebSocket/Worker) stops updating.
This is a regression introduced somewhere after Chromium 83.0.4103.122 and is not present in that version or earlier.

Expected behavior

Mouse movement events should not starve other main thread tasks (IPC, WebSocket, Worker messages) regardless of whether the frame rate is capped or uncapped.

Root Cause?

This has been traced to ShouldPrioritizeInputEvent in:

third_party/blink/renderer/platform/scheduler/main_thread/main_thread_scheduler_impl.cc

Two code paths in this function return true unconditionally in ways that cause the main thread scheduler to deprioritize all other work in favor of mouse input:

1. When a kMouseMove event occurs with kLeftButtonDown held, the function returns true — causing drag/aim input to fully preempt IPC and Worker processing.
2. A catch-all return true at the end of the function causes all other unhandled input event types to also preempt the thread.

Now a patch addressing both of these exists and has been confirmed to fix the issue (but it's only been tested for Linux):

--- a/third_party/blink/renderer/platform/scheduler/main_thread/main_thread_scheduler_impl.cc
+++ b/third_party/blink/renderer/platform/scheduler/main_thread/main_thread_scheduler_impl.cc
@@ -1049,7 +1049,7 @@ bool MainThreadSchedulerImpl::ShouldPrioritizeInputEvent(
        web_input_event.GetType() == blink::WebInputEvent::Type::kMouseMove) &&
       (web_input_event.GetModifiers() &
        blink::WebInputEvent::kLeftButtonDown)) {
-    return true;
+    return false;
   }
   // Ignore all other mouse events because they probably don't signal user
   // interaction needing a smooth framerate. NOTE isMouseEventType returns false
@@ -1060,7 +1060,7 @@ bool MainThreadSchedulerImpl::ShouldPrioritizeInputEvent(
       blink::WebInputEvent::IsKeyboardEventType(web_input_event.GetType())) {
     return false;
   }
-  return true;
+  return false;
 }

This specific patch has been submitted upstream to the Chromium project (https://issues.chromium.org/issues/415071737) but was it seems to declined for upstreaming. Since WebView2 tracks Edge/Chromium, users of WebView2-based applications have no recourse.

Impact

This bug makes --disable-frame-rate-limit effectively unusable for any WebView2 application that depends on real-time WebSocket or Worker communication, which includes web games, trading applications, and any latency-sensitive app. This was previously raised tangentially in #3045, where the workaround of a capped FPS API was requested, but the underlying scheduler bug was not identified at the time. This forces applications to use version 133.0.3065.92 as it is the LAST non-affected WebView2 version.

Environment
Affects all current WebView2 runtime versions (regression from Chromium 83)
Windows 10 / Windows 11 / Linux
Reproducible regardless of GPU or hardware configuration

Related

• WebView2Feedback #3045 — related feature request, same root cause
• Upstream Chromium issue: https://issues.chromium.org/issues/415071737
• Repro repository: https://github.com/6ct/mouse-freeze-bug
• Application using WebView2 version 133.0.3065.92: https://github.com/slavcp/glorp

Importance

Important. My app's user experience is significantly compromised.

Runtime Channel

Prerelease (Edge Canary/Dev/Beta), Stable release (WebView2 Runtime)

Runtime Version

133.0.3065.92

SDK Version

No response

Framework

----Please select----

Operating System

Windows 10, Windows 11, Other

OS Version

Windows 11 Version 10.0.26200 Build 26200

Repro steps

Steps to reproduce:

A minimal reproduction repository already exists for this bug: https://github.com/6ct/mouse-freeze-bug

1. Clone the repo and follow its README
2. Launch with --disable-frame-rate-limit
3. Move the mouse across the window while holding left click
4. Observe that WebSocket and Worker message latency spikes dramatically during mouse movement

Without --disable-frame-rate-limit the effect is significantly reduced, confirming the interaction between uncapped frame rate and input event prioritization.

Repros in Edge Browser

No, issue does not reproduce in the corresponding Edge version

Regression

Regression in newer Runtime

Last working version (if regression)

133.0.3065.92