david.delagneau
1ad707373a
- Created daily log entries for May 13, 14, 18, 19, 20, and 21, capturing work done, findings, and next steps. - Established a daily logs index for easy navigation of daily notes. - Developed templates for daily logs, decisions, meeting notes, people, systems, and work items to standardize documentation. - Introduced base files for filtering and displaying various types of project knowledge, including daily notes, decisions, people, systems, work items, and workstreams. - Added maps for current work, fidelity apps, and fidelity domain to enhance project navigation and context.
2.7 KiB
2.7 KiB
type, project, date, status, focus, work-items, blockers, tags, updated
| type | project | date | status | focus | work-items | blockers | tags | updated | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| daily | fidelity | 2026-04-30 | active |
|
|
2026-05-01 |
2026-04-30
Focus
- Continue the Discourse / FTTransfer AccountLink investigation and verify whether the web-view reload issue is caused by XFlow/XFlowViewMaker or by the consumer SwiftUI hierarchy.
Work Done
- Compared the failing
FTTransferPlaygroundpath with the working non-XFlow entry point Zachary referenced. - Explored whether XFlow event handling could be contributing to the issue, since similar event/lifecycle concerns came up in prior work.
- Ran a deeper architecture analysis of the web-view reload behavior with concrete code references.
- Identified the likely root cause as a SwiftUI view-identity / environment-republish issue around
BankInformationViewandBankSetupWebView, not XFlow rendering or XFlowViewMaker lifecycle logic directly.
Findings
- XFlow is definitely the upstream trigger path, but the failure is driven entirely by how the consumer SwiftUI hierarchy anchors the web-view presentation.
- Final Root Cause (Modifier-Site Teardown): The
.ftFullScreenCovermodifier was incorrectly attached to a volatile branch ofBankInformationView(e.g., inside a dynamic loaded/error state view). When the webview triggered an exit alert, the resulting state mutation caused SwiftUI to re-evaluate that volatile branch. This dismantled the presentation anchor and rebuilt it off-screen (inWindow=false), resulting in a blank screen. - The working non-XFlow route survives because it uses a completely different, stronger modal/coordinator boundary (
BankSetupContainerView), avoiding this fragile modifier placement. - Verified Solution: The issue was resolved by moving the
.ftFullScreenCoverand itsshouldShowWebViewobserver to the stable root ofBankInformationView. By anchoring the presentation to the static root instead of a dynamic child branch, transient state changes no longer dismantle the presenter. This fixes the bug perfectly using pure SwiftUI, without any UIKit (UIHostingController) hacks.
Communication
- David asked Zachary for the working non-XFlow entry point so the failing and working paths could be compared directly.
- David can now confidently update Jeff and Zachary that XFlow is completely cleared, and the bug was a classic SwiftUI presentation-anchor issue in the playground's consumer code.
Next Steps
- Finalize the PR with the structural fix (moving the cover to the stable root of
BankInformationView). - Share the exact lines changed with Zachary so his team can apply this SwiftUI best practice to other covers in their playground.
Blockers
- None currently.