Find in page - Nested/circular embeds & Calendar view issues

Description:

I have identified two separate issues with the in-page search (Ctrl + F / Cmd + F):

1. Find in page incorrectly counts/searches occurrences through nested and circular embeds, which can become severe enough to freeze/crash the app on pages with complex embed relationships.
2. Find in page does not seem to be available from the Calendar view.

Issue 1 — Find in page incorrectly traverses nested/circular embeds

Description:

The in-page search (Ctrl + F / Cmd + F) seems to incorrectly handle pages containing nested, repeated, and circular embeds.

I initially thought that a simple circular embed such as:

• Page A embeds Page B
• Page B embeds Page A

was enough to cause an infinite recursive search.

However, after further testing in a Sandbox workspace, a simple circular embed does not reproduce the crash. There seems to be some protection against directly reopening/researching the current object.

I have nevertheless been able to reproduce a smaller and deterministic version of the problem showing that Find in page incorrectly counts occurrences when objects can be reached through multiple nested embed paths.

Behavior:

1. Incorrect result count / duplicate traversal: Find in page can report more occurrences than actually exist when searching through nested/circular embeds.
2. Incorrect navigation between results: When navigating through those additional results, some of them do not correspond to a distinct visible occurrence. Instead, the search highlights an earlier occurrence of the same embedded object.
3. Complex real-world graph — Browser: On one of my actual notes with more complex MOC/embed relationships, the number of search results keeps increasing into the thousands until the app becomes completely unresponsive.
4. Complex real-world graph — Windows desktop app: The behavior can be even more severe, with Find in page causing the app to freeze/crash.

Reproduction:

A simplified Sandbox reproduction:

1. Create Page A, Page B and Page C.
2. Add the string test once to each page.
3. Embed B and C into A.
4. Embed A and C into B.
5. Embed A and B into C.
6. Open Page A.
7. Search for test.

There are only 3 actual test strings: one in A, one in B and one in C.

However, Find in page reports 5 results.

The traversal appears approximately like this:

• test in A
• test in B embedded in A
• test in C embedded in B embedded in A
• another result corresponding to C through another embed path
• another result corresponding to B through another embed path

The last two are particularly interesting: when navigating to them with "Find next", Capacities does not highlight a new occurrence of test. Instead, it highlights the previously found occurrence in the first rendered instance of C or B.

The issue becomes increasingly visible when the graph is made more complex or when the same objects are embedded multiple times: the reported number of results increases even though the underlying objects do not contain additional occurrences.

Real-world reproduction / isolation:

I can reproduce a much more severe version on one of my actual notes, which I will call Page A.

Page A contains 10 real occurrences of my test search string.

I progressively removed its MOC embeds to isolate the problem:

1. Page A without its MOC embeds → 10 results, as expected. No bug.
2. Page A + Page B only → 10 results, as expected.
3. Page A + Page C only → 57 results instead of 10. It does not crash, but the first 47 results correspond to the embedded content even though it does not contain the searched string. Navigating through them does not highlight actual matching text.
4. Page A + Page B + Page C → same behavior: 57 results.
5. Page A + page D only → the result count starts increasing into very large numbers and eventually causes the app to freeze/crash.

This suggests that the problem is not simply caused by the presence of an embed or by a simple A → B → A circular relationship.

Instead, it seems related to how Find in page traverses more complex graphs of nested/repeated/circular embeds, potentially counting the same underlying objects or matches multiple times when they are reachable through different embed paths.

Expected behavior

• Find in page should continue to search inside embeds and closed toggles.
• Circular references should not cause recursive traversal to continue indefinitely.
• The same underlying searchable content should not generate phantom/duplicate results simply because it can be reached through multiple embed paths.
• Every number reported by the result counter should correspond to an actual occurrence that can be correctly highlighted when navigating through the results.
• Search traversal should safely terminate even with complex graphs of mutually referencing/embedded MOCs.

For example:

With:

• Page A → Page B → Page C
• Page B → Page A
• Page C → Page A / Page B

Find in page should search the relevant embedded content without repeatedly counting/traversing the same content through every possible path.

If A, B and C each contain test once and only those three rendered/searchable instances should be considered, the result count should correspond to those actual searchable occurrences rather than generating additional phantom results through recursive embed paths.

Additional context / impact:

• I use Maps of Content (MOCs) extensively. My notes often contain relationships such as parents, children, breadcrumbs, sub-MOCs, and related MOCs represented through embeds.
• These relationships naturally create complex graphs where the same objects may be reachable through multiple paths and where circular relationships are common.
• Removing the problematic MOC embeds makes Find in page work normally again.
• A simple circular embed alone does not reproduce the crash, so I have not yet isolated the exact graph structure required to trigger the runaway behavior.
• However, the simplified Sandbox reproduction reliably demonstrates the incorrect result counting/navigation, while my real-world note demonstrates that the same kind of problem can become severe enough to produce thousands of results and freeze/crash the app.
• For my workflow, this can make Find in page effectively unusable on most of my most important MOC notes.

Issue 2 — Find in page is unavailable in Calendar view

Description:

Find in page does not seem to be available when using the Calendar view itself.

There is an important distinction between the Calendar view and an individual Daily Note:

• If I open an individual Daily Note from the Calendar (for example 30/09/2026 as an opened object), Find in page works.
• If I am in the actual Calendar view (for example Today), I cannot trigger Find in page.

Behavior:

1. Ctrl + F / Cmd + F does not open Find in page from the Calendar view.
2. I also cannot find the Find in page command in the ... menu while in the Calendar view.
3. Opening an individual Daily Note as an object allows Find in page to work normally, so the issue seems specific to the Calendar view rather than Daily Notes themselves.

Reproduction:

1. Open the Calendar / Today view.
2. Press Ctrl + F / Cmd + F.
3. Nothing happens.
4. Open the ... menu.
5. There is no Find in page command available.
6. Open an individual Daily Note from the Calendar as an object.
7. Find in page is available/works there.

Expected behavior

• Find in page should also be available from the Calendar view.
• Ctrl + F / Cmd + F should trigger it consistently.
• The Find in page command should be available from the ... menu, consistently with regular objects.

Additional context / impact:

• Calendar / Today can contain a significant amount of content, so being able to search the currently displayed page is particularly useful.
• The fact that Find in page works after opening an individual Daily Note, but not from the Calendar view itself, makes this appear to be a separate issue from the nested/circular embed problem described above.