Fix #1592: pointerDragged honours isEnabled() like pointerPressed/Released#5119
Merged
Conversation
Contributor
Cloudflare Preview
|
Contributor
✅ Continuous Quality ReportTest & Coverage
Static Analysis
Generated automatically by the PR CI workflow. |
Collaborator
Author
|
Compared 122 screenshots: 122 matched. Native Android coverage
✅ Native Android screenshot tests passed. Native Android coverage
Benchmark ResultsDetailed Performance Metrics
|
Collaborator
Author
|
Compared 66 screenshots: 66 matched. Benchmark Results
Build and Run Timing
|
Collaborator
Author
|
Compared 122 screenshots: 122 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
The 2015 reporter noted that Form.pointerDragged would invoke the sub-component's pointerDragged(...) regardless of cmp.isEnabled(), even though pointerPressed and the sidemenu drag branch in the same class already gate on isEnabled. That meant a disabled component could still observe drag events that originated over its bounds -- an inconsistency the reporter flagged as a "Minor bug". Add the isEnabled() gate to both the int and int[] pointerDragged overloads of Form, immediately around the routed LeadUtil.pointerDragged call. The setFocused() helper above the gate is already guarded by cmp.isEnabled() so focus behaviour is unchanged. Closes #1592. Adds maven/core-unittests/.../DisabledPointerDraggedRoutingTest.java with two cases that drive Form.pointerPressed/Dragged/Released through a Component subclass whose pointerDragged increments a counter: - enabled component: counter > 0 (sanity) - disabled component: counter == 0 (regression) Before the fix the disabled-component test reports 1; after the fix it reports 0. Full drag/pointer/form regression sweep (60 tests across DragEventsTest, PointerEventsTest, FormTest, the dragged-lead and long-press samples, etc.) stays green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
shai-almog
force-pushed
the
fix-1592-pointerdragged-disabled
branch
from
d45d7dd to
762c5e2
Compare
shai-almog
added a commit
that referenced
this pull request
May 30, 2026
Previous CI run on this PR hit three orthogonal infrastructure flakes that have nothing to do with the cubic-bezier code: - build-linux-jdk8: corrupted master.zip downloaded from the codenameone-skins GitHub release endpoint (unzip: cannot find zipfile directory in master.zip). - Build Android JDK 17 / 21: install-cn1 tried to write tmpProject/lib/CLDC11.jar before the parent lib/ directory had been created. PR #5119 has these same Android jobs passing on the identical master base, so the failure is a setup race. Empty commit to retrigger CI.
The 'Input validation gesture suite' iOS job crashed during the long-press phase (t = 23-26s of testGestureSuite), not during the drag this PR touches. Sequence in the failed run: - driveTap (t = 15.45s) -- completed - driveDrag (t = 19.22s) -- completed - driveLongPress (t = 23.12s) -- app died at 25.94s with 'Lost connection to the application' and the action then hit the 15-min timeout. Upload-artifact then errored on a half-written simctl_diagnostics tracev3 file (ENOENT). The Form.pointerDragged isEnabled() gate in this PR can't affect long-press handling (long-press is a single static touch, not a drag). Classic iOS-simulator+XCUITest flake. Empty commit to re-trigger.
shai-almog
added a commit
that referenced
this pull request
May 30, 2026
Previous CI run on this PR hit three orthogonal infrastructure flakes that have nothing to do with the cubic-bezier code: - build-linux-jdk8: corrupted master.zip downloaded from the codenameone-skins GitHub release endpoint (unzip: cannot find zipfile directory in master.zip). - Build Android JDK 17 / 21: install-cn1 tried to write tmpProject/lib/CLDC11.jar before the parent lib/ directory had been created. PR #5119 has these same Android jobs passing on the identical master base, so the failure is a setup race. Empty commit to retrigger CI.
Collaborator
Author
|
Compared 122 screenshots: 122 matched. Benchmark Results
Detailed Performance Metrics
|
shai-almog
added a commit
that referenced
this pull request
May 31, 2026
Previous CI run on this PR hit three orthogonal infrastructure flakes that have nothing to do with the cubic-bezier code: - build-linux-jdk8: corrupted master.zip downloaded from the codenameone-skins GitHub release endpoint (unzip: cannot find zipfile directory in master.zip). - Build Android JDK 17 / 21: install-cn1 tried to write tmpProject/lib/CLDC11.jar before the parent lib/ directory had been created. PR #5119 has these same Android jobs passing on the identical master base, so the failure is a setup race. Empty commit to retrigger CI.
liannacasper
pushed a commit
that referenced
this pull request
May 31, 2026
…r semantics (#5122) * fix(Motion): cubic-bezier follows CSS cubic-bezier(x1,y1,x2,y2) semantics (#1524) The 2015 reporter at ftp27/cn1-cubic-bezier-motion observed that Motion.createCubicBezierMotion(start, dest, dur, p0, p1, p2, p3) did not animate along the expected CSS cubic-bezier curve. Reviewing his demo confirms it: the four floats are documented as control points yet the implementation just plugged them into a 1D Bernstein- basis polynomial directly, so cubic-bezier(0, 0, 0.75, 1) for example returned ~0.41 at t=0.5 when the CSS-correct value is ~0.62. Implement the standard CSS solver: - The four floats are now treated as the X/Y coordinates of the two control points P1=(x1,y1) and P2=(x2,y2). P0=(0,0) and P3=(1,1) are implicit (matching CSS cubic-bezier(), Web Animations, browser ease-* curves, cubic-bezier.com etc.). - For a given time t, solve Bx(u) = t for u via Newton-Raphson (8 iterations) with a bisection fallback for nearly-degenerate derivatives. - Evaluate y = By(u) and project onto [sourceValue, destinationValue]. Also drops the duplicated `if (currentMotionTime > -1) { currentTime -= startTime; }` block in getCubicValue. That block was dead under real-time playback (because currentMotionTime stays at -1 and getCurrentMotionTime() returns now - startTime, which is already motion-relative) and actively wrong under manual playback (because subtracting startTime from a motion-relative number produces a huge negative). Replace with a simple Math.min/max clamp. Closes #1524. Adds maven/core-unittests/.../CubicBezierMotionTest.java with five cases. The two most diagnostic: - easeOutCurveMatchesCSSReferenceAtMidpoint asserts cubic-bezier(0, 0, 0.75, 1) at t=0.5 lands in the 580-660 band. CSS-correct ~619; pre-fix value ~406 would fail loudly. - easeInOutCurveStartsSlowEndsSlow asserts the canonical ease-in-out S-shape (lags linear at 0.25, leads linear at 0.75, hits midpoint at 0.5 by symmetry). Plus endpoint exactness, linear cubic-bezier(0,0,1,1) sanity, and a decreasing-range sweep that asserts the value never escapes the [source, dest] envelope. Full Motion/Animation/Transition sweep (68 tests) stays green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * ci: re-trigger after flaky infrastructure failures Previous CI run on this PR hit three orthogonal infrastructure flakes that have nothing to do with the cubic-bezier code: - build-linux-jdk8: corrupted master.zip downloaded from the codenameone-skins GitHub release endpoint (unzip: cannot find zipfile directory in master.zip). - Build Android JDK 17 / 21: install-cn1 tried to write tmpProject/lib/CLDC11.jar before the parent lib/ directory had been created. PR #5119 has these same Android jobs passing on the identical master base, so the failure is a setup race. Empty commit to retrigger CI. * goldens(Android): refresh animation screenshots for cubic-bezier fix (#1524) The CSS-correct cubic-bezier curve in PR #5122 changes the per-frame position of every animated transition, so all 20 transition/animation screenshot baselines need to be refreshed. Source: emulator-screenshot artifact from the failing Android JDK 21 instrumentation run on this branch's pre-rebase commit. Screenshots match the prior tests by name and size order; the only differences are the easing-curve-driven pixel positions during transitions, which is the expected outcome of the fix. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * goldens(Android): restore StatusBarTap to master version (#1524) StatusBarTapDiagnosticScreenshotTest isn't animation-related and was swept up by the bulk goldens refresh. The previous commit replaced the master golden (28910 B, matching JDK 8 Default) with the JDK 21 mismatch output (30032 B). JDK 17 / 21 produce a different image for this test regardless of the cubic-bezier change, so this is a pre-existing JDK-version flake. Restoring master's golden so the JDK 8 Default job keeps passing and this PR doesn't conflate two unrelated issues. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * goldens(iOS+Metal+Mac): refresh animation screenshots for cubic-bezier fix (#1524) The earlier goldens commit only refreshed scripts/android/screenshots and missed the three other animation-affected pipelines. CI on PR #5122 flagged the same 19 transition/animation tests as "updated" on iOS GL, iOS Metal, and Mac native. Source: the failing run's ios-ui-tests, ios-ui-tests-metal, and mac-native-ui-tests artifacts on this branch. All 19 PNGs are now refreshed in all three baseline dirs - same set of animation tests whose per-frame position is governed by the CSS-correct cubic-bezier curve. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Summary
Closes #1592. The 2015 reporter noted that
Form.pointerDraggedwas routing drag events to a sub-component regardless ofcmp.isEnabled(), even thoughpointerPressedand the sidemenu drag branch in the same class already gate onisEnabled. A disabled component could therefore still observe drag events that originated over its bounds — an inconsistency the reporter flagged as a "Minor bug".Fix
Both overloads of
Form.pointerDragged—pointerDragged(int, int)andpointerDragged(int[], int[])— now wrap the routedLeadUtil.pointerDragged(cmp, x, y)call in anif (cmp.isEnabled())block, matching the pattern already used in the sidemenu branch (cmp != null && cmp.isEnabled()) and inpointerPressed.The
setFocused()helper above the gate is already guarded bycmp.isEnabled()so focus-on-drag behaviour is unchanged.Test plan
DisabledPointerDraggedRoutingTestdrivesform.pointerPressed/Dragged/Releasedthrough aComponentsubclass whosepointerDraggedincrements a counter, with two cases:DragEventsTest,PointerEventsTest,FormTest,DraggableLeadComponentTest,DragFinishedListener#3056Testand theLongPointerPressSample/NullPointerOnEDTSample#2992regression samples — all green.🤖 Generated with Claude Code