[web] Let the browser handle Control+wheel zoom outside of macOS - #193362

The problem

On Windows and Linux, holding Control and turning the mouse wheel zooms the page in every browser. In a Flutter web app it does nothing: the page does not zoom and the app does not react either. Control+Plus and Control+Minus still work, as the reporter noted, which makes the wheel feel broken rather than deliberately disabled.

Issue: #129933

Root cause

Browsers report a trackpad pinch as a wheel event with ctrlKey set. Since flutter-team-archive/engine#36348 (Flutter 3.10) the web engine turns every wheel event with ctrlKey into a PointerSignalKind.scale and calls preventDefault() on it, so that InteractiveViewer and friends can zoom on pinch. That is right for a pinch. But a user holding the Control key and turning the wheel produces exactly the same event, and gets swallowed with it.

Before that change _handleWheelEvent had this:

if (event.getModifierState('Control') &&
    operatingSystem != OperatingSystem.macOs &&
    operatingSystem != OperatingSystem.iOs) {
  // Ignore Control+wheel events since the default handler
  // will change browser zoom level instead of scrolling.
  return;
}

The macOS path already knows how to tell the two apart: it asks the keyboard converter whether a physical Control key is held, because a pinch never involves a key press. Windows and Linux never got that check, which is how they lost browser zoom.

The fix

_isBrowserZoomShortcut applies the same physical-key check on every platform except macOS and iOS. When the user is holding Control and turning the wheel, _handleWheelEvent returns before forwarding the event to the framework and without cancelling it, so the browser zooms the page the way it does on any other site. A pinch still reaches the framework as a scale signal and is still cancelled, so nothing changes for InteractiveViewer.

macOS keeps its current behaviour on purpose: Control+wheel does not zoom the browser there, and the existing code already reports it as a plain scroll.

The one behavioural change is for an app that relied on getting a PointerScaleEvent from a mouse wheel with Control held on Windows or Linux. That never worked on macOS, did not work before 3.10, and it competes with the browser's own shortcut, so restoring the pre-3.10 behaviour looks like the right call to me. If the team would rather keep delivering the event and only skip preventDefault(), I am happy to change it.

Testing

• New test leaves Control+wheel to the browser outside of macOS in pointer_binding_test.dart covers Windows and Linux: a pinch is delivered as a scale and cancelled, a wheel with Control physically held is neither delivered nor cancelled, and releasing the key brings scrolling back. felt test --gcs-prod --compiler dart2js test/engine/pointer_binding_test.dart passes (73 tests), and I checked that the new test fails without the fix.
• The existing does choose scroll vs scale based on ctrlKey test still passes, so the macOS path is unchanged.
• I do not have a Windows or Linux machine at hand, so I have not exercised this in a real browser yet. The change is small and the unit test pins the exact event flow, but if a reviewer can give it a spin with a mouse on Windows Chrome or Edge, that would be a welcome sanity check.

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the AI contribution guidelines and understand my responsibilities, or I am not using AI tools.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• I followed the breaking change policy and added Data Driven Fixes where supported.
• All existing and new tests are passing.

Notes on the checklist: the only behaviour that changes is described in the table above, and it restores what the engine did before 3.10. There is no API change, so no Data Driven Fixes apply.