iOS: fix status-bar tap-to-scroll-to-top on iOS 13+ scenes (#3589)#4904
Merged
shai-almog merged 3 commits intomasterfrom May 10, 2026
Merged
iOS: fix status-bar tap-to-scroll-to-top on iOS 13+ scenes (#3589)#4904shai-almog merged 3 commits intomasterfrom
shai-almog merged 3 commits intomasterfrom
Conversation
iOS dispatched UIStatusBarTapAction to the scene client but never called scrollViewShouldScrollToTop: on the proxy scroll view, so the tap silently no-op'd on device (verified iPhone 15 Pro Max iOS 26). Three things had to change for UIKit's filter to accept the proxy and for the synthesized tap to land on CN1's StatusBar bar: * alpha=1.0 (was 0.0) with a clearColor background -- iOS 13+ filters fully-transparent scroll views out of scrollsToTop dispatch. * frame pinned to the status-bar strip (was full-screen) via the new cn1UpdateStatusBarTapProxyFrame helper -- a full-screen frame also got skipped. * synthesize the tap at safeAreaInsets.top/2 in native pixels (was y=0) so it lands inside Toolbar's StatusBar Container instead of above it (the Form has a small top padding before the toolbar). Also call setGrabsPointerEvents(true) on the StatusBar Container so Form.getResponderAt finds it for diagnostics, and update the JavaSE simulator's "iOS Status Bar Tap" menu to mirror the new tap coordinates (locate the actual StatusBar component and aim inside). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Collaborator
Author
|
Compared 7 screenshots: 7 matched. |
Contributor
✅ Continuous Quality ReportTest & Coverage
Static Analysis
Generated automatically by the PR CI workflow. |
Collaborator
Author
|
Compared 90 screenshots: 90 matched. Native Android coverage
✅ Native Android screenshot tests passed. Native Android coverage
Benchmark ResultsDetailed Performance Metrics
|
Collaborator
Author
|
Compared 90 screenshots: 90 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
Collaborator
Author
|
Compared 90 screenshots: 90 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
The proxy needs alpha=1.0 with a clearColor backgroundColor so iOS 13+ keeps routing UIStatusBarTapAction → scrollViewShouldScrollToTop: to it, but compositing it through CALayer's renderInContext: (cn1_captureView's fallback path) still introduced a 1-pixel diff that broke every iOS screenshot test. Walk the captured hierarchy, set every CN1StatusBarTapProxyView's alpha to 0 around the render calls, restore afterwards. The existing alpha<=0 short-circuit in cn1_renderViewIntoContext takes care of the rest, and iOS doesn't see the temporary alpha change since the capture runs synchronously on the main thread. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The previous fix hid the proxy via alpha=0 inside cn1_captureView, which appeared to deadlock the Metal screenshot CI (TransformCamera was the last test to start before the 30-min timeout). Drop the alpha-toggling hack and instead install the proxy as a sibling of self.view at the UIWindow level, not as a descendant. * iOS still walks the entire window hierarchy when routing UIStatusBarTapAction → scrollViewShouldScrollToTop:, so the proxy is still found and the status-bar gesture keeps working. * cn1_captureView calls drawViewHierarchyInRect: / renderInContext: on self.view, which only traverses self.view's subtree. With the proxy outside that subtree, screenshot tests are byte-identical to before the #3589 fix. cn1InstallStatusBarTapProxy now waits until self.view.window is set -- viewDidLoad runs before the view enters a window, so the actual installation happens on the viewDidAppear retry path that was already in place. 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
Fixes #3589. iOS 13+ scene-based apps received
UIStatusBarTapAction(visible inlog show) but UIKit silently filtered our scrollsToTop proxy out of the dispatch, so the gesture was a no-op on device. Verified the fix on iPhone 15 Pro Max iOS 26 Simulator: tapping the status bar now triggers the listener and scrolls the form to top.Root cause
Three things had to be true for UIKit to actually call
scrollViewShouldScrollToTop:on our proxy and for the synthesized tap to land on CN1's StatusBar:alpha = 0.0caused iOS 13+ to skip the proxy entirely. Switched toalpha = 1.0with a fully transparentbackgroundColor(still invisible to the user, but iOS counts it as visible).cn1UpdateStatusBarTapProxyFramehelper (FlexibleWidth + FlexibleBottomMargin so it stays glued to the top on rotation).y=0landed above CN1'sStatusBarContainer. The form has a small top padding/margin before the toolbar, so y=0 hitToolbaritself rather than the bar that has the scroll-to-top listener.cn1FireStatusBarTapnow aims atsafeAreaInsets.top/2(in native pixels) so the synthesized tap lands inside the StatusBar bar.Diagnostic counters exposed via
Display.getProperty("cn1.iosStatusBarTap.*")are unchanged so users can still verify on a real device.Changes
Ports/iOSPort/nativeSources/CodenameOne_GLViewController.m— proxyalpha, frame, autoresizing, and the synthesized tap y-coordinate.CodenameOne/src/com/codename1/ui/Toolbar.java—setGrabsPointerEvents(true)on the StatusBar Container soForm.getResponderAt(displayWidth/2, …)finds it.Ports/JavaSE/src/com/codename1/impl/javase/JavaSEPort.java— simulator's "iOS Status Bar Tap" menu now locates the StatusBar component and aims the synthesized tap inside it; report text updated to match.Test plan
Form.pointerPressed/Releasedfires at(displayWidth/2, safeAreaInsets.top/2)→StatusBarContainer's pointer-released listener runs → form scrolls to top.paintsTitleBarBool=true— no regression (status bar tap was already a no-op on those).🤖 Generated with Claude Code