Hi. This bug sneakily deletes html elements from your note under certain conditions, and all the user needs to do is to type text. For me it is a serious bug, so I would be very happy to see it fixed. Thank you all. : )
Steps to reproduce
Create a new note.
Turn on Live-Preview.
Copy paste the below into it.
<img src="emoji-overleaf.png">Random text here, doesn't matter.<img src="emoji-overleaf.png">
Place your cursor exactly at the end of the first </span>
Type pasta. (any two characters suffice actually)
Did you follow the troubleshooting guide? [Y/N]
Yes. I tested in a fresh sandbox.
Expected result
The note should obviously just become:
<img src="emoji-overleaf.png">pastaRandom text here, doesn't matter.<img src="emoji-overleaf.png">
Actual result
The note becomes:
Random text here, doesn't matter.<img src="emoji-overleaf.png">
Ie, <span class="emoji-quark"></span> is deleted. It is NOT simply hidden/invisible, itās gone. You can check this by turning on source-mode, or pressing ctrl+A.
Environment
SYSTEM INFO:
Obsidian version: v1.9.10
Installer version: v1.8.4
Operating system: Windows 11 Pro 10.0.26100
Login status: logged in
Language: en
Catalyst license: none
Insider build toggle: off
Live preview: on
Base theme: adapt to system
Community theme: none
Snippets enabled: 0
Restricted mode: off
Plugins installed: 0
Plugins enabled: 0
RECOMMENDATIONS:
none
Additional information
These are more general conditions under which I believe the bug will always happens:
You must be in Live-Preview.
You must have two occurrences of the exact same (character-for-character) html element in the same note.
If the cursor is at the end of the first occurrence, type any two characters.
Now first occurrence is deleted.
Clarification:
The cursor doesnāt even have to be exactly at the end of the first html element. Typing in other places can delete the first element as well. I think you must be typing in the line that contains the first element though.
I did verify the bug with other html elements like: <span class="emoji-quark"></span> and <span></span> ;
When I previously made a post about this for <span class="emoji-quark"></span>, I didnāt find any reports of this bug.
The behavior also reliably occurs when typing a single character within the word āloremā (so anywhere between the letters ālā and āmā) but only when the line is fresh, as in, when the cursor has freshly reentered the line and before typing other edits.
I noticed this with <br> tags, which are the only HTML element I use frequently in Obsidian, on desktop and mobile. The <br> tag disappears when Iām typing in the line after the break tag.
I also saw some reallyā¦interestingā¦behavior when an internal link was inserted before the <br tag, an example of which I happened to capture in a Loom video demonstrating the bug! (The first time it happened, Iād inserted an internal link with an alias right before the <br> tag, and the link disappeared with it, but the link alias would pop up randomly where the next <br> tag was wherever I clicked. Couldnāt reproduce this in the sandbox, but might be useful info.)
Hereās my sandbox vault environment:
SYSTEM INFO:
Obsidian version: v1.9.10
Installer version: v1.8.4
Operating system: Darwin Kernel Version 24.5.0: Tue Apr 22 19:54:49 PDT 2025; root:xnu-11417.121.6~2/RELEASE_ARM64_T6000 24.5.0
Login status: logged in
Language: en
Catalyst license: none
Insider build toggle: off
Live preview: on
Base theme: adapt to system
Community theme: none
Snippets enabled: 0
Restricted mode: on
ayaac2002, nice, that Loom matches what Iām seeing (and described above): looked like it happened when you typed within the first word that immediately followed the <br> tag (with no spaces between), not when you typed other places.
And it probably wonāt matter to the devās debugging but setting the feedback straight just in case it becomes a sticking point: I donāt know the string of as example that Cawlin mentioned so did not (try to) replicate it.
Itās the example from the original help thread linked in the last sentence of the bug report. Itās not substantially different, just a different sting between the html tags. I just specified in case somehow that explained the difference in what we saw.
Copy this line into the note: Let N' = (Ī£, Q<sub>1</sub> ⨯ Q<sub>2</sub>, įŗ<sub>P</sub>, (s<sub>1</sub>, s<sub>2</sub>), (F<sub>1</sub> ⨯ Q<sub>2</sub>) āŖ (Q<sub>1</sub> ⨯ F<sub>2</sub>)) be the union product NFA, where įŗ<sub>P</sub> : (Q<sub>1</sub> ⨯ Q<sub>2</sub>) ⨯ Ī£ -> 2<sup>Q<sub>1</sub> ⨯ Q<sub>2</sub></sup> is given by įŗ<sub>P</sub>((p<sub>1</sub>, p<sub>2</sub>), c) = įŗ<sub>1</sub>(p<sub>1</sub>, c) ⨯ įŗ<sub>2</sub>(p<sub>2</sub>, c).
Put your cursor between any symbol and the subscript directly after it (for example, between Q and <sub>1</sub>), type a space, then delete it.
Now put your cursor directly before the symbol preceding the subscript (in this example, directly before the Q) and type a space. The subscript tags directly following it disappear. (Some other number of subscript tags may also disappear if you do this a few times.)
Did you follow the troubleshooting guide? [Y/N]
Yes, I set the theme to default, restarted it in restricted mode, Iām not using any snippets, and I also ran it in the appimage version instead of the .deb version.
Expected result
Subscript tags should never disappear.
Actual result
Iāve noticed subscript tags disappearing when you edit the same line and there is a lot of them in the line. Sometimes it is all the subscript tags containing the same text; sometimes all of the subscript tags in the entire line at once⦠if I ctrl+z they come back and I can usually repeat whatever I did to cause it without any effect. It seems to be related to where the cursor previously was. If you try this with just the one superscript tag in the original text, nothing happens, but if you find-and-replace all of the superscript tags to subscript tags, you can reproduce this with superscript tags as well.
It doesnāt seem to affect tags on other lines (even other lines that also have a lot of tags), only the line youāre currently editing.
Environment
SYSTEM INFO:
Obsidian version: v1.9.12
Installer version: v1.9.12
Operating system: #29~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Aug 14 16:52:50 UTC 2 6.14.0-29-generic
Login status: not logged in
Language: en
Insider build toggle: off
Live preview: on
Base theme: adapt to system
Community theme: none
Snippets enabled: 0
Restricted mode: on
I donāt know if it is consistent with the problem this thread is talking about, but I often find that the underline disappears for unknown reasons, as shown in the gif.
Is anything being deleted when that happens? If not, itās probably a separate problem (and if the underline still appears in Reading View, itās a Live Preview quirk).
This bug has a lot of influence on my note taking. I constantly use <i> tags in my notes (<i> because theyāre short), styled with classes refering to stylesheets linked through CSS snippets in the appearance settings. The update has challenged my workflow a lot.
I can confirm everything above, I think. Sometimes the styling is simply removed, leaving unstyled content. Sometimes content is deleted as described by others. I gave up finding the pattern. I can also confirm the extremely weird replacement of content described by @ayac2002above.
Iām on Ubuntu 25.04. I wish I had time to do more debugging, tell me if something specific would help.
Iām having (presumably) the same issue when typing latex and itās crippling. Would love a fix for this, since now Iāve had no choice but to abandon live preview.
Alright, I spent some time trying narrow it down to the essence, using a sandbox vault. I think and hope this can help clarify the issue. There will be some repetition as an attempt to make a boiled down description of everything.
Note:
Leading up to this test session ā with a similar syntax, but in my ordinary vault ā I once again got the weird replacement issue that ayac2002 described above (worst thing about this is that using undo just messes it up even further). In the sandbox vault I couldnāt reproduce this, but what I could reproduce, described below, is what I experience most frequently anyway (which seems to be the same for others?).
Sandbox repro 1
<i>blabla</i>
<i>blabla</i>
Write this in an empty note and add some content to the end of line 1. The outer html (html tags) of line 1 will be deleted after writing 2 characters. Hereās an example of what will happen (copied direrectly from the sandbox, the space is optional):
blabla qw
<i>blabla</i>
Conditions needed
Only happens in live preview (as stated a couple of times)
Only happens if content (āqwā) is added to line 1, not if itās added to line 2
The two lines have to be identical. In my test scenario this was true for both inner html (content, āblablaā) and outer html (tags and potential attributes). I tested with class and style attributes, respectively, and both properties and values had to be identical for the bug to happen. This seems to vary depending on other content in the file, but itās true for this minimal test case.
Sandbox repro 2
<div>blabla</div>
<div>blabla</div>
When replacing i with div, we get a slightly different result (again just adding " qw" to the end of line 1):
blabla
qw
<div>blabla</div>
I assume that because div is a block element (and i is inline), a line break is automatically rendered in live preview when adding content directly afterwards. Even after 1 character (āqā), when the bug has not happened yet. This makes sense and only affects the rendering, not the actual content. However, after adding the second character (āwā), causing the bug to happen, 2 actual line breaks are added (besides removing outer html of line 1 as before). I thought this might reveal some of the logic behind whatever is causing this bug. Or maybe itās two different things.
I hope this helps solving the problem and crushing the bug.