After reopening the last closed tab, navigation in the right pane panel stops working. #365

New Issue

giteasync · 2025-10-01T15:51:27-05:00

giteasync commented

2025-10-01 15:51:27 -05:00

Originally created by @SiriusXT on GitHub.

Description

First, open a text note and then close it. After that, use "Reopen Last Closed Tab" to reopen the note. When clicking entries in the right pane panel, the note can no longer navigate to the target position, and the "Search in Notes" function also becomes unusable.

I tested this after reverting to the zadam/trilium repository, and the same issue still occurs.

TriliumNext Version

0.93.0

What operating system are you using?

Windows

What is your setup?

Local (no sync)

Operating System Version

windows11

Error logs

No response

Originally created by @SiriusXT on GitHub. ### Description First, open a text note and then close it. After that, use "Reopen Last Closed Tab" to reopen the note. When clicking entries in the right pane panel, the note can no longer navigate to the target position, and the "Search in Notes" function also becomes unusable. I tested this after reverting to the zadam/trilium repository, and the same issue still occurs. ### TriliumNext Version 0.93.0 ### What operating system are you using? Windows ### What is your setup? Local (no sync) ### Operating System Version windows11 ### Error logs _No response_

giteasync commented

2025-10-01 15:51:28 -05:00

@SiriusXT commented on GitHub:

Preliminary findings:
Taking apps\client\src\widgets\type_widgets\editable_text.ts as an example, when a tab is closed, its associated editor is not properly disposed. As a result, upon reopen last closed tab, the previously closed tab's executeWithTextEditorEvent still returns an invalid editor.
This causes both getTextEditor and getCodeEditor to return incorrect editor instances.

However, I'm not sure how to fix this issue.

@SiriusXT commented on GitHub: Preliminary findings: Taking apps\client\src\widgets\type_widgets\editable_text.ts as an example, when a tab is closed, its associated editor is not properly disposed. As a result, upon reopen last closed tab, the previously closed tab's executeWithTextEditorEvent still returns an invalid editor. This causes both getTextEditor and getCodeEditor to return incorrect editor instances. However, I'm not sure how to fix this issue.

giteasync commented

2025-10-01 15:51:28 -05:00

@dosubot[bot] commented on GitHub:

The root cause is that when a tab is closed, the associated editor instance (managed by EditorWatchdog in EditableTextTypeWidget) is not explicitly destroyed—cleanup only clears the editor data, not the editor itself. As a result, reopening the tab reuses a stale or invalid editor, which breaks navigation and search features. The tab close workflow in TabManager removes the NoteContext but does not trigger widget/editor disposal, and NoteDetailWidget keeps typeWidgets alive across tab closes, so the editor instance lingers in memory and state.

To fix this, you’ll want to ensure that when a tab is closed (in TabManager’s removeNoteContext or related event), you call a proper disposal method on the associated widget—specifically, call watchdog.destroy() on the editor instance in EditableTextTypeWidget (and similar for code editors). This will guarantee that reopening a tab always creates a fresh, valid editor instance and avoids returning invalid references from getTextEditor or getCodeEditor. You may need to add or enhance a dispose/destroy method in your widget classes and make sure it’s invoked during tab removal, not just on type changes or reinitialization.

References:

To reply, just mention @dosu.

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

@dosubot[bot] commented on GitHub:  The root cause is that when a tab is closed, the associated editor instance (managed by EditorWatchdog in EditableTextTypeWidget) is not explicitly destroyed—cleanup only clears the editor data, not the editor itself. As a result, reopening the tab reuses a stale or invalid editor, which breaks navigation and search features. The tab close workflow in TabManager removes the NoteContext but does not trigger widget/editor disposal, and NoteDetailWidget keeps typeWidgets alive across tab closes, so the editor instance lingers in memory and state. To fix this, you’ll want to ensure that when a tab is closed (in TabManager’s removeNoteContext or related event), you call a proper disposal method on the associated widget—specifically, call watchdog.destroy() on the editor instance in EditableTextTypeWidget (and similar for code editors). This will guarantee that reopening a tab always creates a fresh, valid editor instance and avoids returning invalid references from getTextEditor or getCodeEditor. You may need to add or enhance a dispose/destroy method in your widget classes and make sure it’s invoked during tab removal, not just on type changes or reinitialization. References: - [EditableTextTypeWidget does not destroy the editor on cleanup, only on reinitializeWithData](https://github.com/TriliumNext/Trilium/blob/20018b9c21f245cafa0ac56e8628fc353d5f4b0b/apps/client/src/widgets/type_widgets/editable_text.ts) - [TabManager removes NoteContext but does not dispose widgets/editors](https://github.com/TriliumNext/Trilium/blob/20018b9c21f245cafa0ac56e8628fc353d5f4b0b/apps/client/src/components/tab_manager.ts) - [NoteDetailWidget keeps typeWidgets alive across tab closes](https://github.com/TriliumNext/Trilium/blob/20018b9c21f245cafa0ac56e8628fc353d5f4b0b/apps/client/src/widgets/note_detail.ts)  *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/9f8cb524-dab4-45ce-84e5-8f25b04f5199?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/9f8cb524-dab4-45ce-84e5-8f25b04f5199?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/9f8cb524-dab4-45ce-84e5-8f25b04f5199?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/9f8cb524-dab4-45ce-84e5-8f25b04f5199?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/9f8cb524-dab4-45ce-84e5-8f25b04f5199?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/9f8cb524-dab4-45ce-84e5-8f25b04f5199?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/9f8cb524-dab4-45ce-84e5-8f25b04f5199?feedback_type=other)</sup>  [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/4af773a7-9840-4978-96dc-c436f6f437cf/ask?utm_source=github) [![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot) [![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/TriliumNext/Trilium/issues/5740)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: TriliumNext/Trilium#365