Repository navigation
Change behavior to render unprocessable HTML to plain text paragraph node #903
Description
When mdx-editor encounters 'bad' html, it throws an error, and in some cases just shows 'blank'
It is my opinion a more ideal solution to render said html as a paragraph node (maybe event with a colored dashed border decoration which alerts the end user of the error on hover, but more on this later)
This could work by 'aborting' the block which the bad html exists in; rendering that entire block as a plain text paragraph node
I was able to quickly slap together a patch; without thinking about optimization. It works by splitting the entire document by block or \n\n then catch'ing the error then rendering based on the result.
A more optimized solution could be to work within the flow of the parser; but I struggled a bit to surface the error back to the parent after the step inside
The following is a proof of concept patch; which I admittedly achieved one-shotting claude-code.
I would like your thoughts/opinions (is this even a behavior you'd like?), then I can put together a more thought out proper PR
diff --git a/node_modules/@mdxeditor/editor/dist/plugins/core/index.js b/node_modules/@mdxeditor/editor/dist/plugins/core/index.js
index 633b343..7f3e980 100644
--- a/node_modules/@mdxeditor/editor/dist/plugins/core/index.js
+++ b/node_modules/@mdxeditor/editor/dist/plugins/core/index.js
@@ -362,13 +362,36 @@ const createActiveEditorSubscription$ = Appender(activeEditorSubscriptions$, (r,
}
]);
});
+function fixCommonHtmlIssues(markdown) {
+ let fixed = markdown;
+
+ // Fix self-closing tags that aren't properly closed
+ // Match tags like <br>, <hr>, <img ...>, etc. that aren't self-closed
+ const selfClosingTags = ['br', 'hr', 'img', 'input', 'meta', 'link', 'area', 'base', 'col', 'embed', 'param', 'source', 'track', 'wbr'];
+
+ selfClosingTags.forEach(tag => {
+ // Replace <tag> with <tag />
+ const simpleRegex = new RegExp(`<${tag}>`, 'gi');
+ fixed = fixed.replace(simpleRegex, `<${tag} />`);
+
+ // Replace <tag attr="value"> with <tag attr="value" />
+ const withAttrsRegex = new RegExp(`<${tag}\\s+([^>]*[^/])>`, 'gi');
+ fixed = fixed.replace(withAttrsRegex, `<${tag} $1 />`);
+ });
+
+ return fixed;
+}
+
function tryImportingMarkdown(r, node, markdownValue) {
+ // Pre-process markdown to fix common HTML issues
+ const fixedMarkdown = fixCommonHtmlIssues(markdownValue);
+
try {
importMarkdownToLexical({
root: node,
visitors: r.getValue(importVisitors$),
mdastExtensions: r.getValue(mdastExtensions$),
- markdown: markdownValue,
+ markdown: fixedMarkdown,
syntaxExtensions: r.getValue(syntaxExtensions$),
jsxComponentDescriptors: r.getValue(jsxComponentDescriptors$),
directiveDescriptors: r.getValue(directiveDescriptors$),
@@ -377,12 +400,41 @@ function tryImportingMarkdown(r, node, markdownValue) {
r.pub(markdownProcessingError$, null);
} catch (e) {
if (e instanceof MarkdownParseError || e instanceof UnrecognizedMarkdownConstructError) {
+ // Try to import block by block to isolate the problematic content
+ const blocks = fixedMarkdown.split(/\n\n+/);
+
+ let hasError = false;
+ blocks.forEach((block, index) => {
+ if (block.trim() === '') return;
+
+ try {
+ importMarkdownToLexical({
+ root: node,
+ visitors: r.getValue(importVisitors$),
+ mdastExtensions: r.getValue(mdastExtensions$),
+ markdown: block,
+ syntaxExtensions: r.getValue(syntaxExtensions$),
+ jsxComponentDescriptors: r.getValue(jsxComponentDescriptors$),
+ directiveDescriptors: r.getValue(directiveDescriptors$),
+ codeBlockEditorDescriptors: r.getValue(codeBlockEditorDescriptors$)
+ });
+ } catch (blockError) {
+ hasError = true;
+
+ // Render this specific block as plain text
+ const paragraphNode = $createParagraphNode();
+ const textNode = new TextNode(block);
+ paragraphNode.append(textNode);
+ node.append(paragraphNode);
+ }
+ });
+
r.pubIn({
[markdown$]: markdownValue,
- [markdownProcessingError$]: {
+ [markdownProcessingError$]: hasError ? {
error: e.message,
source: markdownValue
- }
+ } : null
});
} else {
throw e;
Activity
petyosi commentedon Feb 13, 2026
@rbbydotdev with LLMs this is a real concern. Initially, I was hoping for enforcing strictness as means to ensure that the editor will be "a point of cleaning up" the markdown, but with LLMs this is no longer practical.
I need to think this through.
rbbydotdev commentedon Feb 13, 2026
I believe the 'spirit' of markdown is to degrade gracefully and avoid strict parsing failures. I say spirit because there are now so many different renderers out there.
For example
[click here](https://example.comstill should render, even if the result is plain text. Or a simpler example is**some textwill just render as**some textIn the same way, I think
<a href="/api/browser/proxy?url=https%3A%2F%2Fexample.com">click hereshould render as well.The one issue I can see possibly come up is in the patch, I am modifying the input. This has obvious pitfalls.
I would also suggest, displaying disabled text of the malformed html with a tooltip explaining the issue on hover, or something like that.
Anyways, I guess this could go against your original philosophy as you stated, so feel free to close the issue if it does not align 👍
petyosi commentedon Feb 13, 2026
My original philosophy no longer holds true in these times :). I'm just not sure if there's a better, more performant way to deal with this.
reergymerej commentedon May 12, 2026
Sooo... when we hit unclosed tags, we should just expect the editor to be blank?