[Android] Fix WebView scrolling inside ScrollView

[Shalini-Ashokan]

Note

Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!

Issue Details

WebView does not scroll when placed inside a ScrollView. The parent ScrollView intercepts vertical touch gestures, preventing the WebView from scrolling its internal content.

Root Cause

The parent ScrollView was intercepting all touch events without checking if the child WebView needed to scroll. This prevented the WebView from receiving touch events and handling its own scrolling.

Description of Change

Added touch event handling to prevent parent interception when WebView scrolls. When touch begins or continues, WebView requests exclusive control from parent. When touch ends or cancels, control returns to parent. This enables WebView scrolling while preserving normal parent-child interaction.

Validated the behavior in the following platforms

• Android
• Windows
• iOS
• Mac

Issues Fixed

Fixes #32971

Output ScreenShot

Before	After
BeforeFix.mov	AfterFix-32971.mov

[dotnet-policy-service]

Hey there @@Shalini-Ashokan! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[Copilot]

Pull request overview

Fixes Android WebView scrolling when nested inside a ScrollView by adjusting touch handling so the WebView can retain vertical gesture control when appropriate.

Changes:

• Override MauiWebView.OnTouchEvent on Android to disallow parent touch interception during WebView scroll gestures.
• Add a new UI test + host app repro page for issue #32971.
• Update Android PublicAPI unshipped surface to include the override.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.

File	Description
src/Core/src/PublicAPI/net-android/PublicAPI.Unshipped.txt	Records the new Android public override for API tracking.
src/Core/src/Platform/Android/MauiWebView.cs	Adds touch handling to prevent parent ScrollView from intercepting WebView scroll gestures.
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue32971.cs	Adds a UI test intended to verify WebView can scroll inside a ScrollView.
src/Controls/tests/TestCases.HostApp/Issues/Issue32971.cs	Adds a repro page that checks WebView scroll position via JS.

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 33133

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 33133"

[kubaflo]

Could you please review the AI's suggestions?

[Shalini-Ashokan]

Could you please review the AI's suggestions?

@kubaflo, I checked the AI review concerns.

Fix concern: The unconditional RequestDisallowInterceptTouchEvent(true) on Down/Move is gesture-scoped — it resets on Up/Cancel, so the parent is never permanently blocked. Android's WebView.OnTouchEvent already returns true (consuming all touches), so the intercept flag is consistent with existing behavior. Tested manually with a non-scrollable WebView inside ScrollView — no regression.

Test concern: App.ScrollDown("TestScrollView") performs a drag gesture at the center of the element, which lands directly on the 600px WebView. Without the fix, the parent steals the gesture so pageYOffset stays 0 and the test fails. With the fix, the WebView scrolls internally and the test passes. The test correctly proves the fix works.

[kubaflo]

Could you please resolve conflicts?

[Shalini-Ashokan]

Could you please resolve conflicts?

@kubaflo, I have resolved the conflicts.

[kubaflo]

Code Review — PR #33133

Independent Assessment

What this changes: Adds OnTouchEvent override to MauiWebView (Android) that calls Parent?.RequestDisallowInterceptTouchEvent(true) on Down/Move and false on Up/Cancel. This prevents a parent ScrollView from intercepting touch events, allowing the WebView to handle its own internal scrolling.

Inferred motivation: When a WebView is inside a ScrollView on Android, the parent intercepts all vertical touch gestures, preventing the WebView from scrolling its internal content.

Reconciliation with PR Narrative

Agreement: ✅ Code matches the description. Standard Android nested-scrolling pattern. The RequestDisallowInterceptTouchEvent approach is the same mechanism used by MauiSwipeView in this repo.

---

Findings

✅ Good — Follows existing repo pattern

MauiSwipeView.cs (lines 332-357) uses the same Parent?.RequestDisallowInterceptTouchEvent pattern with the same gesture lifecycle: true on Down/Move, false on Up/Cancel. The pattern is established in the codebase.

✅ Good — Null safety

• e == null → returns false early (addressed prior reviewer concern — avoids passing null to base.OnTouchEvent)
• Parent?. null conditional on all RequestDisallowInterceptTouchEvent calls
• base.OnTouchEvent(e) always called for non-null events

✅ Good — PublicAPI.Unshipped.txt

Correctly updated for net-android with the new override signature.

---

⚠️ Concern — Unconditional parent interception blocking

The WebView always requests exclusive touch control on Down/Move, regardless of whether its content actually needs scrolling. Compare with the existing pattern in MauiSwipeView:

// MauiSwipeView — CONDITIONAL (only when gesture is handled)
case MotionEventActions.Down:
    handled = HandleTouchInteractions(GestureStatus.Started, point);
    if (handled == true)
        Parent?.RequestDisallowInterceptTouchEvent(true);

// MauiWebView (this PR) — UNCONDITIONAL
case MotionEventActions.Down:
    Parent?.RequestDisallowInterceptTouchEvent(true);

Impact: If a WebView's content fits without scrolling (no internal scrollbar), a drag gesture starting over the WebView area will block the parent ScrollView from scrolling during that gesture. The user would need to touch outside the WebView to scroll the parent.

The author tested this and says the parent scrolls normally — which is true between gestures (the flag resets on Up/Cancel), but during a single drag gesture the parent IS blocked.

Suggestion: Consider checking canScrollVertically() before blocking:

case MotionEventActions.Move:
    if (CanScrollVertically(1) || CanScrollVertically(-1))
        Parent?.RequestDisallowInterceptTouchEvent(true);
    break;

This would only block the parent when the WebView actually has content to scroll. However, I acknowledge this adds complexity and the simple approach works for the reported use case.

💡 Suggestion — Combine identical Down/Move cases

Minor style nit — the Down and Move cases do the same thing:

case MotionEventActions.Down:
case MotionEventActions.Move:
    Parent?.RequestDisallowInterceptTouchEvent(true);
    break;

💡 Suggestion — Test targets WebView scroll specifically

The test scrolls TestScrollView (parent) via App.ScrollDown("TestScrollView"). Whether this actually exercises the WebView's internal scrolling depends on where Appium performs the gesture:

• If the gesture lands over the WebView area: ✅ tests the fix (WebView consumes the scroll)
• If the gesture lands outside the WebView: ❌ tests parent scrolling (doesn't exercise the fix)

The prior reviewer raised this and the author confirmed changing to TestWebView fails because Appium can't find the element. This is a known WebView accessibility limitation. The current test likely works because the WebView occupies most of the scroll area. Consider adding a comment explaining this.

ℹ️ Note — Target branch is inflight/current

This PR targets inflight/current, not main. Ensure this is intentional for the release branch.

ℹ️ Note — CI Status

Multiple CI failures (Windows builds, Helix tests, iOS integration). The Windows build failures are concerning for an Android-only change — these may be inflight/current branch infrastructure issues rather than problems introduced by this PR. Worth verifying.

---

Devil's Advocate

• "Will this break gestures on pages with non-scrollable WebViews?" — Within a single drag gesture, yes — the parent won't scroll if the touch starts on the WebView. Between gestures, no — the flag resets. This is a tradeoff: the fix prioritizes WebView internal scrolling over parent scrolling. For most apps where WebViews have scrollable content, this is the correct tradeoff.
• "Should e.ActionMasked be used instead of e.Action?" — For single-touch scrolling, e.Action is fine. Multi-touch (pinch-to-zoom) fires continuous Move events which keep the flag set. The prior reviewer's concern is technically valid but not a practical issue.
• "Is this Android-specific code safe for the repo?" — Yes. The file is Platform/Android/MauiWebView.cs, Android-only. No cross-platform impact.

Verdict: LGTM with one concern

Confidence: medium-high
Summary: Correct fix for a real issue using an established Android pattern. The unconditional parent interception blocking (⚠️ above) is the main concern — it could affect parent ScrollView scrollability when touching a non-scrollable WebView. However, this matches common Android practice and the author verified it works. The canScrollVertically() guard would be more robust but adds complexity. Acceptable for merge, but the concern should be noted for future regression investigation if parent scrolling issues are reported with nested WebViews.

Review performed by Copilot CLI using the code-review skill

[kubaflo]

Could you please verify the new ai comments?

[Shalini-Ashokan]

Could you please verify the new ai comments?

@kubaflo,
Concern 1 — Unconditional parent interception blocking:
Valid observation but not actionable. WebView has no gesture handler to check whether the gesture was handled (unlike SwipeView), and CanScrollVertically() is unreliable for WebView due to asynchronous content loading. The unconditional approach is the standard Android pattern for WebView-in-ScrollView. No change needed.

Suggestion 1 — Combine identical Down/Move cases:
Valid. I've updated the changes.

Suggestion 2 — Test targets WebView scroll specifically:
Valid observation but not actionable. App.ScrollDown("TestScrollView") lands on the 600px WebView since it occupies most of the scroll area. Targeting "TestWebView" directly fails due to Appium's inability to find WebView elements by AutomationId (known platform limitation). The current test works correctly.

[kubaflo]

Code Review — PR #33133

Independent Assessment

What this changes: Overrides OnTouchEvent in MauiWebView (Android) to call Parent?.RequestDisallowInterceptTouchEvent(true) on Down/Move and false on Up/Cancel. This prevents a parent ScrollView from intercepting touches while the user is actively interacting with the WebView. Adds a UI test and the correct PublicAPI entry.

Inferred motivation: When a WebView is nested inside a ScrollView on Android, the ScrollView intercepts all vertical touch events via OnInterceptTouchEvent, preventing the WebView from scrolling its own web content.

Reconciliation with PR Narrative

Author claims: WebView scrolling is blocked by parent ScrollView; fix prevents parent interception during WebView touch.
Agreement: My independent assessment matches the author's description exactly. The root cause is correct — Android's ScrollView intercepts touches before the WebView can handle them.

Findings

⚠️ Warning — Unconditional parent interception blocking

MauiWebView.cs:55-68: The interception block is unconditional — it always prevents parent scroll on Down/Move regardless of whether the WebView actually has scrollable content. A WebView with content shorter than its height will still block the parent ScrollView from scrolling when the user touches the WebView area.

Compare to MauiSwipeView.cs:89+ which checks ShouldInterceptTouch() before blocking. A more precise approach would check canScrollVertically() before blocking.

Mitigating context: The author addressed this in PR comments — Android WebView's canScrollVertically() is unreliable for asynchronously loaded web content, and there's no cross-platform gesture handler to query. This is a known Android limitation. The unconditional approach is the standard Android pattern for WebView-in-ScrollView (and is what StackOverflow/Google recommends). Acceptable as-is, but worth noting for awareness.

⚠️ Warning — MauiHybridWebView has the same gap

MauiHybridWebView.cs extends AWebView and does NOT have this OnTouchEvent override. If a HybridWebView is placed inside a ScrollView, it would exhibit the same scrolling problem. Consider filing a follow-up issue.

💡 Suggestion — PR targets inflight/current instead of main

The PR targets inflight/current branch. Per contribution guidelines, main is the default target for bug fixes. If this is intentional (e.g., targeting a specific release), no action needed — just flagging for visibility.

💡 Suggestion — Test scrolls the outer ScrollView, not the WebView directly

Issue32971.cs (test): App.ScrollDown("TestScrollView") performs a scroll gesture on the outer ScrollView element. The test works because the gesture hits the WebView child area and triggers the touch interception fix. However, a more direct test would scroll within the WebView element itself (App.ScrollDown("TestWebView")) to make the test intent clearer. This is minor — the current test does validate the fix correctly.

CI Status

CI failures are NOT caused by this PR:

• Build failures: Issue34310.cs has Grid ambiguous reference — unrelated file
• Helix unit test failures: Microsoft.Maui.Controls.Core.UnitTests.dll — pre-existing
• Integration test (Samples windows) failure — pre-existing

Devil's Advocate

1. Could this break parent scrolling permanently? No — interception is released on Up/Cancel, so the parent regains control when the touch ends.
2. Could this break gesture recognizers? No — base.OnTouchEvent(e) is still called, which handles taps/gestures. RequestDisallowInterceptTouchEvent only affects the parent's interception pipeline.
3. Null safety? Parent?. handles the case where there's no parent. e == null returns false early. Both correct.
4. What about multi-touch? Code uses e.Action (not e.ActionMasked), which is fine here — secondary pointer events won't match the switch cases, so interception state only changes on the primary pointer. This matches MauiSwipeView's pattern.

Verdict: LGTM

Confidence: high
Summary: Clean, targeted Android fix using a well-established RequestDisallowInterceptTouchEvent pattern. The approach matches existing patterns in the codebase (MauiSwipeView). The unconditional interception is a reasonable trade-off given WebView's asynchronous content loading. PublicAPI entry is correct. Test validates the fix. CI failures are unrelated. The only actionable follow-up would be filing an issue for the same gap in MauiHybridWebView.