Editing Broken iPhone 11 iOS 26.5.2

Bug graveyard
, ,
1

Once you’ve done the above, delete everything above this line.

Steps to reproduce

Open any note on iPhone, attempt to make edits, especially on long notes. Use bold format button. Notes that use internal links to headings also persist in highlighting the destination. So have a link to a heading like display. Click it. The target section will be irrevocably highlighted. If you attempt to edit, wild glitches occur such as cursor moving to bottom of section, text gets rearranged, large gaps appear, edits don’t save. Sometimes toggling edit mode helps, sometimes not.

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

Please, follow the Troubleshooting Guide before answering Yes.

yes.

Expected result

I expect editing to work as it always has. I expect clicking into the target heading section to deselect the highlighting and enable normal editing.

Actual result

Highlighting of target section persists. Edits, even without having clicked on an internal link sometimes glitch out, memorably when using the bold formatting button in the edit ribbon.

Environment

iPhone 11, iOS 26.5.2

Additional information

Tried to reinstall. Didn’t fix it.

2

Does it happen in a new vault?

What is the output of show debug info command?

3

Yes, it happens in a new vault, and I can reproduce it:

create two new notes, one called abc and the other 123. In each, paste the following:

h1

H1

Some

interesting

  • informatio

(In fact, you can see above how “information” was truncated, which demonstrates the problem, so I haven’t corrected it.)

Now use the sidebar search function to search for either note by name, 123 in my case. The note name will be highlighted in the search results. Click to open it. Attempt to make edits. You should experience glitchy behavior.

I do not believe I have access to debug information on iOS. Please correct me if I’m wrong. This behavior does not seem to manifest on Windows 11 nor LMDE 7.

My suspicion is that the search function is interfering somehow with the editing. It cannot be a large index because it happens in a new vault. It cannot be a weird install state because I recently reinstalled and resynced my old vault. It only seems to happen, I may be wrong, when searching for a note, opening it while it’s still highlighted in the sidebar, then editing it. Of course, one cannot be in the sidebar search tab and unhighlight the note without making it disappear from the list, so this means search will necessarily block successful edits, if this is indeed the problem, and it is severe and persistent, even across restarts of the device.

Or, forgive me, I believe that the actual conflict is from the highlight location feature, which is active in both sidebar search as well as internal heading links. I say this because I just again tested whether a note in the dashboard, a pinned one, would do this after clicking the [h1](#h1) link, and yes the pinned note glitches.

If I may add, for a while sometimes the internal heading links, as I’ve just formatted, become occasionally unclickable. This forces me to fully restart the app for them to become active again. How directly related to this possible highlighting-editing issue it is, I don’t know.

Thank you for looking into it. Again, if I can provide debug info in iOS, I’m happy to do so.

4

It seems that a new bug report was added 2h ago which may be related to this one:

5

I can’t edit my reply now, but please add this instruction to the reproduce steps:

After opening the searched for note by clicking it, click the [h1](#h1) heading link, then attempt to make edits. This should ensure the behavior is erratic.

Thanks.

6

Seems like a duplicate of