Typing in Live-Preview can delete an entire HTML element tag

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

  1. Create a new note.
  2. Turn on Live-Preview.
  3. Copy paste the below into it.
<img src="emoji-overleaf.png">Random text here, doesn't matter.<img src="emoji-overleaf.png">
  1. Place your cursor exactly at the end of the first </span>
  2. 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:

  1. You must be in Live-Preview.
  2. You must have two occurrences of the exact same (character-for-character) html element in the same note.
  3. If the cursor is at the end of the first occurrence, type any two characters.
  4. 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.

5 Likes

This simplification might help your report. In each of these examples, type two characters directly before ā€œloremā€ to reproduce.

Tags that have been closed or are self-closing exhibit the behavior:

<br>lorem<br>
<img src="a">lorem<img src="a">

Open tags do not exhibit the behavior :

<span>lorem<span>

… until you close them, at which point they take on the behavior:

<span></span>lorem<span></span>

The behavior occurs when the entire string of HTML tags and optional content are identical:

<span class="a">identical text</span>lorem<span class="a">identical text</span>

Only the tag(s) are removed; enclosed text and interstitial text remain:

<div>identical text</div>lorem<div>identical text</div>

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 was able to reproduce (My span elements disappear when I type text in their line - #4 by CawlinTeffid). Unlike Dawni, I was not able (on iOS) to reproduce by typing only 2 characters (before a string of as as given in the original example in the Help thread). I didn’t try 3 or 4.

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.)

This Loom captures the <br> tag disappearing as well as some wild behavior with an internal link: Testing HTML Tag Issues in Obsidian šŸž | Loom

I’ve attached the .md test file from the sandbox vault.
HTML break tag testing.md (446 Bytes)

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

RECOMMENDATIONS:
none

2 Likes

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.

1 Like

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

Steps to reproduce


9

First, enter it in the second line.

![](file:///D:%5Cppp.webp)<span class="x">x</span>

Then, re-enter it in the first line again.

! [](file:///D:%5Cppp.webp)<span class="x">x</span>

After that, if you input any more text, it will overwrite the content of the first line.

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

Y

Expected result

Actual result

Environment

Sandbox 1.9.12


Additional information

1 Like

thanks

Steps to reproduce

  1. Create a new note
  2. 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).
  3. 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.
  4. 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

RECOMMENDATIONS:
none

1 Like

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.
underline

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 @ayac2002 above.

I’m on Ubuntu 25.04. I wish I had time to do more debugging, tell me if something specific would help.

1 Like

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.

2 Likes

Yes. The <u> and </u> are deleted, like others said.

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.

will be fixed 1.10.2. No ETAs.

3 Likes

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.