feat(swift-ios): add pull-down command drawer by saphid · Pull Request #7345 · pingdotgg/t3code

No issues identified (13 code objects reviewed).

• Reviewed files modified since 97ef938; other PR files not modified since then were skipped.
• Merge Base: b678379
• Head: c1eef5a

✅	File Path	U3 Bytes	Comments Posted	Reason
✅	`apps/swift-ios/Features/Workspace/FeatureCommandDrawerView.swift`	2450	0
➖	`apps/swift-ios/Tests/FeatureTests/FeatureCommandDrawerTests.swift`	1101		Excluded by default ignore patterns
✅	`apps/swift-ios/Features/Workspace/FeatureCommandDrawerPresentationView.swift`	1973	0

Billed Total: 10.00KB of diff | $0.50 (This review was charged at our per-review byte minimum of 10.00KB. Learn more here)

apps/swift-ios/Features/Workspace/FeatureCommandDrawerPresentationView.swift

line 123: The keyboard observers accept every app-wide keyboard notification, including ones emitted by another foreground scene. In a multi-window iPad app, a keyboard frame for the other scene can satisfy the overlap test and update this drawer, and its subsequent keyboardWillHideNotification unconditionally resets keyboardHeight to zero. Thus an open drawer in this scene can resize to the wrong edge or extend behind its still-visible keyboard. UIKit documents that these notifications identify only the UIScreen (or nil before iOS 16.1), not the owning UIWindow, so the existing scene-local windowReference does not filter them. [ Already posted ]

apps/swift-ios/Features/Workspace/FeatureCommandDrawerView.swift

line 459: shouldBeRequiredToFailBy establishes that the drawer recognizer must fail when otherGestureRecognizer (the scroll view's pan recognizer) recognizes. Since takesPriority returns true for that recognizer, a vertical pull starting in the grab band within a scroll view lets the scroll pan win and prevents the drawer from reaching .began, contrary to the intended drawer-over-scroll ordering. Use the inverse failure-requirement delegate method for this priority. [ Already posted ]
line 459: shouldBeRequiredToFailBy has the failure relationship reversed. Returning true for a scroll view's pan makes this drawer recognizer wait for that scroll recognizer to fail, so a vertical pull beginning in the grab band is claimed by the scroll view and the drawer cannot begin. The priority condition belongs in shouldRequireFailureOf (or must otherwise require the scroll pan to fail). [ Already posted ]