Regression: Even in a new vault, typing "[[Untit#" shows "No match found" instead of autocompleting as "[[Untitled#]]"

[blake_n]

I’ve attached the test.zip vault resulting from Steps to reproduce below, leaving off just prior to typing the # and triggering the issue.

This regression appears on Android since the recent update to Obsidian v1.9.14 (242). I have linked several related topics in Additional information below and explain why this differs from those. Notably, this is not due to the usual suspect, a change in link suggestions after 10000 items, nor is it precisely like any of the recently reported issues related to heading links.

I’ve tried this on Windows, iPad, and Android, and only observe this behavior on Android.

Steps to reproduce

• Open Obsidian v1.9.14 (242) on Android.
• Start from a fresh vault.
  • If already in a vault, swipe/tap to open the left sidebar and tap the vault dropdown in the top-left corner, tap “Manage vaults…”.
  • Tap “Create new vault”.
  • Name the vault test.
  • Select “Device storage” as the vault location.
  • Tap “Create”.
  • Tap “Use this folder” e.g. in the default Documents folder.
• Create two notes and attempt to link to a header in the first note from the second note.
  • Tap “Create new note”. A new note named Untitled will be created.
  • Tap in the body of the note and type a single heading, # Test.
  • Swipe/tap to open the left sidebar and tap the “Create new note” icon. A new note named Untitled 1 will be created.
• Regression observed here: Tap in the body of the Untitled 1 note, select the [] icon in the mobile toolbar, and begin typing an internal (deep) link.
  • Type [[untit]], the autocomplete menu will have two options, Untitled, and Untitled 1. Verify that Untitled is highlighted in this menu.
  • Don’t tap anything, instead type # at the cursor after the t in [[untit]]. At this point, I recall observing Expected result prior to the Obsidian v1.9.14 (242) update yesterday on all platforms, including Android. As of yesterday, I observe Actual result.

Did you follow the troubleshooting guide? [Y/N]

Y

Expected result

The text should autocomplete to read [[Untitled#]] and the autocomplete menu should update to list the headings in the Untitled note, namely just the H1 heading Test. From here, further typing should filter headings down, and tapping a heading should complete it.

From my testing, Windows and iPad exhibit this expected behavior, while Android differs as below.

Actual result

No auto-completion, instead, after typing # we just see [[untit#]] and the autocomplete menu says “No match found”.

Another notable change in behavior since v1.9.14 (actually observed on all platforms) is that if you tap on e.g. Untitled instead of typing #, the link will complete to Untitled, then if you “Undo”, the autocomplete menu will have an additional entry at the top, untit, and this entry will be highlighted. This behavior change was surprising to me, is actually observed on all platforms, and may or may not be related to this issue.

Environment

SYSTEM INFO:
	Operating system: android 16 (Google Pixel 6a)
	Webview version: 140.0.7339.207
	Obsidian version: 1.9.14 (242)
	API version: v1.9.14
	Login status: logged in
	Language: en
	Catalyst license: supporter
	Live preview: on
	Base theme: adapt to system
	Community theme: none
	Snippets enabled: 0
	Restricted mode: on

RECOMMENDATIONS:
	none

---

Additional information

The following are more like QoL requests for aspects of deep, multi-header linking, e.g. [[Note#Header#Subheader]] completion:

Deep link ([[note_name#Header#Sub Header]]): broken completion

I see. Perhaps this? You could then use a higher heading to specify the one you actually want, like in [[#heading c#heading a]] to get to the last appearance of “heading a”. You can’t use auto complete to find that though… And it does require for a somewhat proper heading structure in your document. With 2 headings of same name in file can only link to first one - #3 by holroy

Making deep links easier

Currently I can deep link to headlines inside pages. That’s not as fine grained as Roam makes linking (where I can link to any “paragraph” (block)), but I find it ok for now Maybe even better in the long run because it makes you think a little bit more about structure, but not too much. I just started with Obsidian and need to play around with it. However: Headlines are no first class citizens in search during linking. After [[ only page titles appear. That means I have to know in which …

As mentioned above, the usual culprit, the algorithm change at 10000 items is not related to this issue:

Options to control the Quick Switcher / Links Suggestion algorithm above 10000 items / Ignore spaces

Hey Use case or problem Actually, when the threshold of 10’000 notes (attached files included) is exceeded, the quick search algorithm used is changed by a simplier one (see @koala answer here) Example So for example if I write “cpt” [image] I would like to obtain the list of all titles containing the letters “c”, “p” and “t” that are in the same order, including all notes about “comportement”. For example [image] In fact, I obtain nothing. [image] Because I’ve reached the th…

Wiki link autocomplete cannot do fuzzy search in large vault

Updates 2023/10/14 It seems clear to me now that 10000 searchable items will cause this behavior (according to White noise and my testing.) This includes files (attachments included), broken links and aliases. For further information, see Options to control the Quick Switcher algorithm above 10’000 files - Feature requests - Obsidian Forum 2023/10/9 I deleted some useless files, and the problem went away (for now). My current file count is 7538, with 661 broken links. Steps to reproduce St…

Link to heading autocomplete showing "No Match Found" when the heading is typed entirely

thanks

The following showed up in my search as well, but aren’t quite related to this:

Fuzzy search doesn't work in linking/autocomplete

Ok, we did some investigation. There is nothing wrong. You have a large number of links to non-existing files in your notes. The total number in searchable items is 29K >10K.

Page link relative paths with `../` fail to autocomplete with "no match found" error

Steps to reproduce Open Sanbox vault Open a sub-page such as “Get started with Obsidian” Type [[ and start typing “…/Start Here”. Note how autocomplete fails with “no match found” error Now set Options > Files and links > New link format > Relative path to file Type [[ and start typing “…/Start Here”. This will also fail the same way. Type [[ and start typing “Start Here”. This time it will autocomplete. Press Enter to insert [[../Start Here|Start Here]]. Now delete the display label (the 2nd “…

When Entering Wikilinks into List Item Properties and No Match Is Found its Name Is Truncated/Shortened to the Cursor

Steps to reproduce Create a property with list items for a file. Enter [[<text> for to be added to the list. Make sure there’s No match found Place the cursor somewhere not at the end of the text and press Enter. (see https://youtu.be/WEBLNa-zTkg) Did you follow the troubleshooting guide? Y Expected result A file with the whole text entered should be registered. Actual result The entered text is truncated to the cursor. Environment SYSTEM INFO: Obsidian version: v1.9.10 Installer version:…

test.zip (2.3 KB)

[blake_n]

I can’t edit any more but to clarify the language below, “the autocomplete menu will have an additional entry at the top, untit”, this is observed only if the autocomplete menu disappears before executing the “Undo” command. That dangling untit entry at the top of the autocomplete menu is self-referential and is an invalid/broken “filename”, and if somehow that’s “poisoning” the autocomplete on Android then maybe that untit file jumps into the menu as # is typed on Android, intercepting auto-complete somehow.

Note that if you fully type out the filename on Android, e.g. [[Untitled]], then type #, you see [[Untitled#]] and autocomplete shows headings in the Untitled note as expected. So maybe this has something to do with the autocomplete menu being “re-rendered” instantaneously as # is typed on Android, and since untit is at the top of the menu, then Untitled is momentarily not highlighted in that instant, and therefore we see “No match found”. Just a hunch.

@blake_n

Another notable change in behavior since v1.9.14 (actually observed on all platforms) is that if you tap on e.g. Untitled instead of typing #, the link will complete to Untitled, then if you “Undo”, the autocomplete menu will have an additional entry at the top, untit, and this entry will be highlighted. This behavior change was surprising to me, is actually observed on all platforms, and may or may not be related to this issue.

[WhiteNoise]

thanks

[WhiteNoise]

So I double checked this and it never worked on mobile with soft keyboard. I tested a couple of past releases.
This is not a regression. Please, open a FR for it.