Repository navigation
iOS: publish the view size after a modal hides a rotation (#6080) - #6085
Conversation
Rotating an iPhone while a full-screen modal that supports only portrait covers the Codename One view (the UIImagePickerController camera) delivers no viewWillTransitionToSize: when the modal is dismissed. The view comes back laid out landscape while the framework keeps the portrait size, so every form draws stretched until the next rotation. viewDidLayoutSubviews now publishes any size the transition callbacks did not, as the Catalyst/tvOS path already does. NativeModalRotationTest reproduces it on the simulator: it presents a portrait-only modal, locks landscape under it, dismisses it and compares the display size with the view's pixel size. Without the fix it fails with "view is 2532x1170 pixels but the display is 1170x2532". Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
✅ Continuous Quality ReportTest & Coverage
Static Analysis
Generated automatically by the PR CI workflow. |
…ed to iOS Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Cloudflare Preview
|
|
Compared 178 screenshots: 178 matched. Native Android coverage
✅ Native Android screenshot tests passed. Native Android coverage
Benchmark ResultsDetailed Performance Metrics
|
|
Compared 214 screenshots: 214 matched. |
|
Compared 193 screenshots: 193 matched. Benchmark ResultsDetailed Performance Metrics
|
|
Compared 193 screenshots: 193 matched. Benchmark ResultsDetailed Performance Metrics
ParparVM vs HotSpot (JDK 25): Windows x64Runner CPU: Intel64 Family 6 Model 207 Stepping 2, GenuineIntel (baseline 1 improvement past the baseline (not a failure; rebaseline to lock it in):
Ratios are ParparVM / JDK 25: below 1.00x ParparVM is faster (time) or smaller (RAM). Median of 5 interleaved, paired rounds; every run's output was verified. A ratio more than 20% (time) / 25% (RAM) above its baseline in
A change that moves performance ON PURPOSE records the new baseline in Result: no regression (improved past the baseline: consider rebaselining) |
|
Compared 193 screenshots: 193 matched. ParparVM vs HotSpot (JDK 25): Linux x64Runner CPU: AMD EPYC 7763 64-Core Processor (baseline Ratios are ParparVM / JDK 25: below 1.00x ParparVM is faster (time) or smaller (RAM). Median of 5 interleaved, paired rounds; every run's output was verified. A ratio more than 20% (time) / 25% (RAM) above its baseline in
Result: no regression |
|
Compared 193 screenshots: 193 matched. ParparVM vs HotSpot (JDK 25): Linux arm64Runner CPU: Neoverse-N2 (baseline Ratios are ParparVM / JDK 25: below 1.00x ParparVM is faster (time) or smaller (RAM). Median of 5 interleaved, paired rounds; every run's output was verified. A ratio more than 20% (time) / 25% (RAM) above its baseline in
Result: no regression |
|
Compared 193 screenshots: 193 matched. Benchmark ResultsDetailed Performance Metrics
ParparVM vs HotSpot (JDK 25): Windows arm64Runner CPU: ARMv8 (64-bit) Family 8 Model D49 Revision 0, MICROSOFT CORPORATION (baseline Ratios are ParparVM / JDK 25: below 1.00x ParparVM is faster (time) or smaller (RAM). Median of 5 interleaved, paired rounds; every run's output was verified. A ratio more than 20% (time) / 25% (RAM) above its baseline in
Result: no regression |
|
Compared 175 screenshots: 175 matched. Benchmark Results
Detailed Performance Metrics
|
|
Compared 179 screenshots: 179 matched. Benchmark Results
Detailed Performance Metrics
ParparVM vs HotSpot (JDK 25): macOS arm64Runner CPU: Apple M1 (Virtual) (baseline Ratios are ParparVM / JDK 25: below 1.00x ParparVM is faster (time) or smaller (RAM). Median of 5 interleaved, paired rounds; every run's output was verified. A ratio more than 20% (time) / 25% (RAM) above its baseline in
Result: no regression |
|
Compared 171 screenshots: 171 matched. |
|
Compared 176 screenshots: 176 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
|
Compared 236 screenshots: 236 matched. |
|
Compared 176 screenshots: 176 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
Fixes #6080.
On an iPhone, rotating the device while a full-screen modal that only supports portrait covers the Codename One view (the
UIImagePickerControllercamera, forCapture.capturePhoto/captureVideo) delivers noviewWillTransitionToSize:when the modal is dismissed. The view comes back laid out landscape while the framework keeps the portrait size, so every form draws stretched until the device is rotated again.Fix
CodenameOne_GLViewControllergets an iOSviewDidLayoutSubviewsthat publishes any view size the transition callbacks did not: framebuffer resize,screenSizeChanged, repaint. That is the same sequenceviewWillTransitionToSize:runs. It returns at the size comparison in the usual case, where the transition already published the size. It skips the background-snapshot layout (isAppSuspended) for the same reason the transition handler does. Catalyst and tvOS keep their existing debounced version.Test
NativeModalRotationTest(hellocodenameone, iOS only, no screenshot) presents a native portrait-only full-screen modal, locks landscape under it, dismisses it and asserts that the display size equals the view's pixel size. Other platforms get stub native implementations and finish immediately. It runs right afterOrientationLockScreenshotTestand restores portrait itself.Verified locally on the iPhone 16e simulator (iOS 26.3):
view is 2532x1170 pixels but the display is 1170x2532 (issue #6080)🤖 Generated with Claude Code