Conversation
LogsView wraps itself in its own NavigationStack and is pushed inside the Settings tab's stack. SwiftUI's behaviour with nested NavigationStacks is inconsistent: NavigationLink(value:) pushes from inside the nested stack can silently route to the *outer* stack, which in this case had no DeviceRoute / GroupRoute handler. Result: tapping the device/group hero card on a log opened via Settings → Logs did nothing — the user perceived it as being dropped back to the tab root. Register the same handlers on SettingsView and BridgeSettingsView NavigationStacks as a safety net so the push lands correctly no matter which enclosing stack SwiftUI picks. The handlers inside LogsView's own stack are kept too, so the in-tab Logs path also still works. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
tashda
added
bug
Root cause of the Settings → Logs → device card regression: LogsView wrapped itself in its own NavigationStack and was simultaneously pushed inside the Settings tab's stack. SwiftUI's value-based push routing in nested NavigationStacks is unreliable — the same NavigationLink(value:) could land on either stack depending on iOS version. The earlier hotfix that mirrored destinations on every outer stack only patched half the problem and left the cards still mis-routing on some paths. Restructure: LogsView is never a tab root, so it has no business owning a NavigationStack. Drop the wrapper; let the host provide the stack: - Settings → Logs and BridgeSettings → Logs already push LogsView onto their own stacks, which now also carry the DeviceRoute / GroupRoute destinations (kept from the previous hotfix). - LogSheetHost (Home → Recent Events, notification taps) now wraps LogsView in a NavigationStack at the sheet level and registers the same destinations. Also: drop the trailing chevron on the compact DeviceCard when it's non-interactive (e.g. log detail of an entry already under that device's own log feed) so the disclosure affordance doesn't lie about the tap target. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The card rendered inside LogDetailView previously used the value-based overlay pattern (NavigationLink(value: DeviceRoute) on top of the visible card with .opacity(0)). LogDetailView itself is reached via a closure-based NavigationLink push from the row in LogsView. Mixing the two push styles inside one stack confused SwiftUI's path management: the value push from inside LogDetail mutated the path, which forced an ancestor re-render that re-fired the row's closure-based push, re-opening LogDetailView on top instead of pushing DeviceDetail. Switch every push from inside log detail to closure-based as well — device hero card, group hero card, and the multi-device list section in LogDetailDevicesSection. No more value-based pushes inside log detail; no more mixed-stack confusion. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two issues from the previous attempt: - The compact DeviceCard rendered its own trailing chevron AND the enclosing NavigationLink + List added a system chevron — so the row showed two of them stacked. - The originDeviceIEEE guard suppressed navigation when the log was opened from the same device's own log feed. The intent was to avoid a "back to where I came from" loop but in practice it was confusing and inconsistent with the rest of the app. Strip both: drop the chevron from the compact DeviceCard (the row's disclosure indicator carries it), and remove the originDeviceIEEE parameter so every device hero card in log detail navigates to the device page regardless of entry point. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The previous attempt removed DeviceCard's internal chevron and relied on the List's auto-disclosure indicator from the NavigationLink-as-row pattern. That only got rid of one of the two chevrons — the system one sat outside the rounded card; the user wants the chevron inside the card where it has always been. Restore the DeviceCard's internal chevron and switch to the ZStack-with-overlay pattern: card on the bottom, an invisible NavigationLink overlay (closure-based, so no value-based path mixing with the row's own push) provides the tap target. The List doesn't auto-add a system disclosure indicator because the row's primary content is the card, not the link. Same fix applied to the group hero card. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Multi-bridge polish: the Settings → Notifications about section showed a single "Bridge Log Level" reading from the focused bridge, hiding any divergence across bridges. With 2+ bridges connected, render one row per bridge labeled by its display name. Category visibility now uses the most verbose level across all bridges so anything a bridge could emit stays configurable. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
tashda
changed the title
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
Two small fixes bundled into v1.6.2:
Log-detail navigation hotfix — regression spotted post-merge of v1.6.1: tapping the device or group hero card on a log entry opened via Settings → Logs silently failed and the user perceived it as being dropped back to the tab root. Root cause: SwiftUI's behaviour with nested
NavigationStacks is inconsistent.LogsViewwraps itself in its ownNavigationStackand is pushed inside the Settings tab's stack.NavigationLink(value:)pushes from the inner stack can route to the outer stack, which had noDeviceRoute/GroupRoutehandler. Fix: register the same destinations onSettingsViewandBridgeSettingsViewouterNavigationStacks as a safety net. The handlers insideLogsView's own stack are kept untouched so the in-tab Logs path still works.Per-bridge Bridge Log Level rows in Notification Settings — required before multi-bridge can ship. Settings → Notifications previously showed a single "Bridge Log Level" reading from the focused bridge, hiding any divergence across bridges. With 2+ bridges connected, the about section now renders one row per bridge labelled by its display name. Category visibility uses the most verbose level across all bridges so anything any bridge could emit stays configurable.
Bumps
MARKETING_VERSIONto 1.6.2. Carries the device-options fix already shipped in v1.6.1 plus the in-flight signing-config fix from #97.Test plan
🤖 Generated with Claude Code