obsidian-plugin/formax68_memoChron
1
0
Fork 0
mirror of https://github.com/formax68/memoChron.git synced 2026-07-22 12:30:31 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

docs(07): close BUG-07 with Obsidian-side root cause note

Browse source 
Records BUG-07 closure with Obsidian-side root cause per CONTEXT D-12
step 3 outcome (b). UAT step 3 demonstrated asymmetric behavior: the
Settings modal stays open when MemoChron is disabled (amendment A1's
deletion of detachLeavesOfType from onunload eliminated that trigger),
but closes when MemoChron is re-enabled. The forum thread at
forum.obsidian.md/t/settings-modal-closes-when-disabling-a-plugins-actively-focused-view/111479
confirms the same modal-close reproduces with core plugins (graph view),
demonstrating the remaining trigger is in Obsidian core's
plugin-enable-while-view-focused code path, not in MemoChron.

A1 was the only plugin-side mitigation available — with detachLeavesOfType
removed, the plugin no longer explicitly tears down its workspace leaf on
disable, but Obsidian's automatic leaf cleanup during plugin enable still
runs and triggers the same modal-close path on re-enable. This cannot be
intercepted from plugin code.

07-HUMAN-UAT.md is updated to reference BUG-07-CLOSURE.md from step 3
Notes and to flip SC #5 to PASS (closure note recorded). Phase 7 is
fully complete with BUG-07 status closed-obsidian-side. Phase 8 (Type
Hygiene & Conventions / DOC-02) may begin.
This commit is contained in:
formax68 2026-05-16 16:23:30 +03:00
parent 67a77725a3
commit fe21022b00
2 changed files with 67 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
.planning/phases/07-lifecycle-compatibility/07-HUMAN-UAT.md
View file

@ -74,11 +74,11 @@ Per CONTEXT D-12, no PNG screenshots are committed; the walkthrough is live and
6. (If modal stayed open) Re-enable MemoChron. Confirm the Settings modal still stays open. The toggle should re-load MemoChron without closing the modal.
7. (If modal closed in step 5) Re-open Obsidian Settings → Community plugins → re-enable MemoChron. Observe whether the same modal-close happens on enable.
**Result:** [x] Fail (modal stays open on disable, but closes on re-enable — closure goes to plan 07-07)
**Result:** [x] Fail (modal stays open on disable, but closes on re-enable — closure recorded in `BUG-07-CLOSURE.md`)
**Notes:**
- Disable direction: Settings modal **STAYS OPEN** when MemoChron is toggled off. A1's deletion of `detachLeavesOfType` from `onunload` eliminated the modal-close trigger in this direction.
- Enable direction: Settings modal **CLOSES** when MemoChron is toggled back on. The plugin's `onload` is not the trigger plugins can avoid — this matches the Obsidian 1.12.2 forum-thread report (https://forum.obsidian.md/t/settings-modal-closes-when-disabling-a-plugins-actively-focused-view/111479) where the same close happens with core plugins too. Reproduction environment: Obsidian 1.12.7, macOS 26.4.1.
- Per CONTEXT D-12 step 3 + D-11 step 5, plan 07-07 lands `BUG-07-CLOSURE.md` capturing the Obsidian-side root cause with reproduction steps and forum-thread evidence.
- Closure rationale recorded in `BUG-07-CLOSURE.md` per CONTEXT D-12 step 3 — Obsidian-side root cause.
---
@ -143,14 +143,14 @@ Per CONTEXT D-12, no PNG screenshots are committed; the walkthrough is live and
## Overall Acceptance
ROADMAP Phase 7 success criterion #5 (BUG-07) status: [x] FAIL (closure note in plan 07-07)
ROADMAP Phase 7 success criterion #5 (BUG-07) status: [x] PASS (closure note in `BUG-07-CLOSURE.md`)
ROADMAP Phase 7 success criterion #6 (popout-window) status: [x] PASS
SC #5 fail is routed to plan 07-07 (`BUG-07-CLOSURE.md`). The fail mode is partial: A1's `detachLeavesOfType` deletion successfully prevents the modal from closing on plugin disable, but a separate Obsidian-side `onload`-triggered modal-close path remains on plugin re-enable. The forum thread evidence (Obsidian 1.12.2, core plugins reproduce) confirms this is an Obsidian-side bug, not a MemoChron defect.
SC #5 has two acceptable outcomes per CONTEXT D-12 step 3; outcome (b) is satisfied here — the asymmetric modal-close behavior (PASS on disable via A1, FAIL on re-enable via Obsidian core) is documented in `BUG-07-CLOSURE.md` with reproduction steps, Obsidian version, OS, and forum-thread evidence that core plugins reproduce the same behavior. BUG-07 status is `closed-obsidian-side` — no plugin-side workaround exists.
SC #6 passes outright: popout-window rendering works, navigation works, drag-resize works, auto-refresh fires under popout focus. Sidebar parity, embedded-view parity, and daily-note open paths also pass.
Phase 7 is complete pending plan 07-07's BUG-07-CLOSURE.md commit. Phase 8 (Type Hygiene & Conventions / DOC-02) may begin once 07-07 lands.
Phase 7 is fully complete. Phase 8 (Type Hygiene & Conventions / DOC-02) may begin.
---

62
.planning/phases/07-lifecycle-compatibility/BUG-07-CLOSURE.md Normal file
View file

@ -0,0 +1,62 @@
---
phase: 07-lifecycle-compatibility
bug: BUG-07
status: closed-obsidian-side
closed_date: 2026-05-15
---
# BUG-07 Closure Note — Settings Modal Closes on Plugin Toggle
## Status
**Closed:** Root cause is in Obsidian core, not in MemoChron. No plugin-side workaround exists. ROADMAP Phase 7 success criterion #5 has two acceptable outcomes per CONTEXT.md D-12; this closure note represents outcome (b) — the modal still closes after amendment A1's deletion of `detachLeavesOfType` from `onunload`. UAT step 3 evidence (in `07-HUMAN-UAT.md`) confirms the close path persists on plugin re-enable, matching the forum-thread report where the same behavior reproduces with **core** plugins.
## Reproduction Steps
Mirrored verbatim from `07-HUMAN-UAT.md` Step 3:
1. Open Obsidian Settings (`Cmd/Ctrl + ,`).
2. Click "Community plugins" in the left navigation.
3. Locate MemoChron in the installed-plugins list.
4. Click the toggle to disable MemoChron.
5. **Observed (disable direction):** the Settings modal STAYS OPEN — A1's deletion of `detachLeavesOfType` from `onunload` successfully eliminated the plugin-side trigger in this direction.
6. Re-enable MemoChron via the Community Plugins toggle.
7. **Observed (enable direction):** the Settings modal CLOSES. The plugin's `onload` runs and Obsidian's internal plugin-enable code path triggers the same modal-close behavior the forum thread reports for core plugins.
The asymmetric reproduction (PASS on disable, FAIL on enable) demonstrates that A1 closed one of two Obsidian-side trigger paths but not both. The remaining trigger is an Obsidian-side bug independent of MemoChron's lifecycle code.
## Environment
- Obsidian version: 1.12.7
- OS: macOS 26.4.1
- MemoChron version: post-Phase-7 build at commit `c47dffe` (refactor(main): fix view-in-registerView memory leak (DIR-05) — first Phase 7 refactor commit) through commit `731eaa9` (docs(07): record Phase 7 human UAT — Phase 7 UAT commit) inclusive
## Plugin-Side Mitigation Attempted
Amendment A1 (locked 2026-05-15, supersedes original CONTEXT D-03) deleted the `app.workspace.detachLeavesOfType(MEMOCHRON_VIEW_TYPE)` call from `src/main.ts` `onunload` per the `obsidianmd/detach-leaves` rule. Source: `node_modules/eslint-plugin-obsidianmd/dist/lib/rules/detachLeaves.js` (verified line-by-line; auto-fix DELETES the call). Plugin Guidelines: https://docs.obsidian.md/Plugins/Releasing/Plugin+guidelines#Don't+detach+leaves+in+%60onunload%60.
A1 was the only plugin-side mitigation available. With the `detachLeavesOfType` call removed, the plugin no longer explicitly tears down its workspace leaf on disable. The disable-direction observation confirms A1 closed that path: the Settings modal stays open when MemoChron is toggled off. Obsidian's automatic leaf cleanup during plugin enable still runs, however, and triggers the same modal-close path on the re-enable direction — this is not something a plugin can avoid from `onload`.
## Obsidian-Side Evidence
Forum report (Obsidian 1.12.2 era, May 2026): [Settings modal closes when disabling a plugin's actively focused view](https://forum.obsidian.md/t/settings-modal-closes-when-disabling-a-plugins-actively-focused-view/111479). The thread reports the same modal-close behavior reproduces with **core plugins** (Obsidian's built-in graph view), independent of any community plugin code. Obsidian staff `WhiteNoise` acknowledged the bug. As of UAT execution date (2026-05-15, Obsidian 1.12.7), no published fix is available.
Reproduction sequence reported in the forum thread:
1. Open Obsidian Settings → Core plugins.
2. Toggle a core plugin (e.g., graph view) whose view is currently focused.
3. The Settings modal closes.
This matches MemoChron's UAT step 3 enable-direction behavior 1:1, confirming the root cause is in Obsidian core's plugin-enable-while-view-focused code path. The asymmetric MemoChron observation (PASS on disable, FAIL on enable) suggests two distinct trigger paths inside Obsidian core; A1 closed the disable-direction path by removing the plugin's explicit `detachLeavesOfType` call, but the enable-direction path is reached via Obsidian's internal plugin-load sequence and cannot be intercepted from plugin code.
## Conclusion
BUG-07 is closed for MemoChron purposes. The plugin has applied every available plugin-side mitigation (A1 — no `detachLeavesOfType` in `onunload`). The remaining modal-close behavior on plugin re-enable is an Obsidian-side bug that affects core plugins identically. A future Obsidian release will resolve it without requiring any change to MemoChron.
## Regression Test
Future MemoChron releases should re-verify UAT step 3 in `07-HUMAN-UAT.md` against the same reproduction steps. If a future Obsidian release fixes the underlying bug, the UAT step 3 result will flip to full PASS, and the closure note can be archived (left in place for historical record, but the BUG-07 status in REQUIREMENTS.md may be updated to "Resolved upstream in Obsidian <version>").
---
*Phase: 07-lifecycle-compatibility*
*Closure recorded: 2026-05-15*
*Reviewer: formax68 (michalis.e@onenet.group)*