MOBILE-341: Let the block's drag play by the device's rules - #217
Merged
Merged
Conversation
added 2 commits
September 2, 2026 04:34
The horizontal drag recognizer handed to the platform view is built by hand, so nothing gave it the device's touch slop the way the framework gives it to every scrollable. Left to itself it fell back to kTouchSlop — 18 logical pixels against the 8 an Android scrollable plays with — and a parent that wants the same direction crossed its threshold first: the arena closed before the block was anywhere near its own, and the native carousel was never told a finger had been on it. A PageView around the block turned the page while the feed stood still; a vertical list never showed it, because it measures the other axis. The recognizer now takes DeviceGestureSettings from MediaQuery, so the block plays by the same rules as everyone else on the screen and wins the drag as the one closest to the finger. Nothing is exposed to hosts — there was no handle for this to begin with. Checked by hand on both platforms, on the PageView tab of the demo's scroll scenarios. Android reproduces the bug without the change and is correct with it, while a drag beside the block still turns the page. iOS behaves the same either way: it reports no device touch slop, so both claimants already sat at kTouchSlop and the block already won on being nearest — the change is a no-op there, kept for the platform that needs it.
The released 2.16.0-rc carries the embedded block hooks the widget leans on, so the iOS manifest goes back to the published tag instead of the working copy it had to point at while those hooks lived only on a branch. The podspec follows it, and the Android side moves to the same release. mindbox-common is named explicitly because @InternalMindboxApi lives there and mobile-sdk does not re-export it: without it the plugin's Kotlin does not compile. It is compileOnly — the annotation is needed to build against the SDK, not to ship alongside it.
There was a problem hiding this comment.
🟡 Changes recommended
The new Flutter APIs are incompatible with the package’s declared Flutter 2.0 minimum.
Get a fresh assessment by requesting another Copilot review.
Pull request overview
Aligns embedded-block drag recognition with device touch-slop settings and upgrades native SDK dependencies.
Changes:
- Applies
MediaQuerygesture settings to horizontal drags. - Adds PageView gesture-arena tests.
- Upgrades native SDKs to
2.16.0-rc.
File summaries
| File | Description |
|---|---|
mindbox/lib/src/embedded_block.dart |
Applies device gesture settings. |
mindbox/test/embedded_block_test.dart |
Tests competing horizontal drags. |
mindbox_android/android/build.gradle |
Updates Android dependencies. |
mindbox_ios/ios/mindbox_ios/Package.swift |
Updates the Swift package dependency. |
mindbox_ios/ios/mindbox_ios.podspec |
Updates CocoaPods dependencies. |
Review details
- Files reviewed: 5/5 changed files
- Comments generated: 1
- Review effort level: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
The packages claimed Flutter 2.0 while the recognizer reached for MediaQuery's aspect accessor, which only exists from 3.10: pub would install the plugin on an older SDK and the host would then fail to compile it. The settings themselves have been on MediaQueryData since 2.8, so reading the data whole asks for far less and returns the same value. The floor moves to 3.0 across the four packages — the first Flutter 3, with room to spare over what the code actually needs. A platform view keeps the recognizer it was first handed, so watching all of MediaQuery instead of one aspect costs nothing here: either way the settings are read once.
added 2 commits
September 14, 2026 18:49
Both the CI job and the script run by hand rewrote one line by name — the mobile-sdk dependency — so the mindbox-common pin added beside it would have kept the previous version while everything around it moved, and nothing checked: the Gradle file had no assertion at all, and branch protection only reads the root pubspec. The substitution now covers any cloud.mindbox artifact in the file, the two named today are asserted the way the iOS pins already are, and a sweep afterwards stops the release on anything still holding another version — a dependency nobody thought to name here, or one written in quotes the pattern does not reach. The same hole was closed in react-native-sdk in #222; this is its counterpart, and it covers both places a release can be cut from.
The Dart floor was still the one set when the packages went null-safe, and it no longer says anything: Flutter 3.0 carries Dart 2.17, so nothing below that can reach these packages anyway. Naming 2.17 costs nothing and leaves one fewer constraint that means less than it appears to. Nothing in the four packages asks for a later language: no records, no patterns, no class modifiers, not even super parameters.
justSmK
approved these changes
Sep 14, 2026
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.
The drag
The block hands the platform view a horizontal drag recognizer that is built by hand, so
nothing gave it the touch slop of the device the way the framework gives it to every
scrollable. Left to itself it fell back to
kTouchSlop— 18 logical pixels against the 8 anAndroid scrollable plays with — and a parent that wants the same direction crossed its
threshold first: the arena closed before the block was anywhere near its own, and the native
carousel was never told a finger had been on it. A
PageViewaround the block turned the pagewhile the feed stood still; a vertical list never showed the problem, because it measures the
other axis.
The recognizer now takes
DeviceGestureSettingsfromMediaQuery, so the block plays by thesame rules as everyone else on the screen and wins the drag as the one closest to the finger.
Nothing is exposed to hosts — there was no handle for this to begin with.
The native versions
The second commit moves the native SDKs to
2.16.0-rc. The released tag carries the embeddedblock hooks, so the iOS manifest goes back to the published version instead of the working copy
it had to point at while those hooks lived only on a branch; the podspec and the Android
dependency follow.
mindbox-commonis named explicitly because@InternalMindboxApilives there andmobile-sdkdoes not re-export it — without it the plugin's Kotlin does not compile. It is
compileOnly:the annotation is needed to build against the SDK, not to ship alongside it.
Checks
Both platforms driven by hand on the PageView tab of the demo's scroll scenarios:
twice out of two — and is correct with it: six swipes (both directions, three speeds, two
positions inside the block) leave the page alone, while a drag beside the block still turns it.
already sat at
kTouchSlopand the block already won on being nearest. The change is a no-opthere, kept for the platform that needs it.
2.16.0-rc, and the SDK's own example app still builds.One thing the stand could not show: the demo place serves two stories and they fit on screen, so
the carousel has nowhere to scroll. What was verified is that the block takes the drag — not
that the feed moves under it. That needs a place with four or more stories.
Note for the demo repository
The demo app carries its own package reference for the notification extensions, and it asked for
a version range. A range never matches a pre-release, so the app-side pin has to become exact
before it can build against
2.16.0-rc. That change lives influtter-app, not here.🤖 Generated with Claude Code