fix(survey): box-none touch pass-through for non-overlay surveys#19
Open
pandeymangg wants to merge 1 commit into
Open
fix(survey): box-none touch pass-through for non-overlay surveys#19pandeymangg wants to merge 1 commit into
pandeymangg wants to merge 1 commit into
Conversation
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



What & why
While a survey was active, the host app received no touch input anywhere — the entire screen was blocked until the survey closed, regardless of placement. This breaks the box-none requirement from ENG-1342 (taps outside the active survey area must reach the host) and RN parity (
pointerEvents="box-none").Fixes ENG-1496.
Root cause
Two independent layers each blocked the full screen:
RawDialogRoute, which always installs a full-screenModalBarrier. A transparentbarrierColoronly makes it invisible; it still absorbs every pointer.RN gets box-none for free from OS WebView hit-test pass-through (the page's
pointer-events:nonefalls through). Flutter's platform-view embedding hit-tests its entire rect and ignores page-levelpointer-events, so the host must mask pointers itself — and it needs the card's geometry to know where the card is.Approach
Presentation now bifurcates on whether the survey uses a backdrop:
overlay: dark/light) → keep the full-screen modal route. Blocking the host is correct here; the web runtime draws the dim and handlesclickOutsidevia its existingonClosebridge call.OverlayEntrywrapped in a_PointerMask. The WebView still paints full-bleed (so shadows render), but only pointers inside the reported card rect hit it; everything outside falls through to the host (box-none). Before geometry arrives, nothing is interactive.To know the card rect, the survey page now reports it over the JS bridge:
Geometrymessage carries the[role="dialog"]card'sgetBoundingClientRect().requestAnimationFrameloop tracks the rect during open/step animations and posts only on change, then idles after ~1.5s of stability;MutationObserver+resize/orientationchangerestart it on later changes.Changes
webview_event.dart— newGeometryEvent(Rect?)+ parser for{type:'Geometry', data:{x,y,width,height}|null}.survey_html.dart— geometry reporting JS; scoped selector#fbjs [role="dialog"][aria-modal="true"].survey_webview.dart— overlay vs non-overlay presentation split,_PointerMaskrender object, geometry plumbing, unified teardown.Testing
flutter analyzeclean; full suite (279 tests) green.🤖 Generated with Claude Code