WebAssembly functionally broken between 0.28.1 and 0.29.0 #534

Closed
opened 2026-01-29 14:38:58 +00:00 by claunia · 8 comments
Owner

Originally created by @wleader on GitHub (Apr 22, 2022).

I was testing with some very simple code and I have observed the following:

This code does work in a .Net 6.0 Console application with version 0.29.0 & 0.28.1
This code does work in a .Net 6.0 Blazor Web Assembly project with version 0.28.1 and several earlier versions (28.0, 27.0, 22.0).
This code does not work in a .Net 6.0 Blazor Web Assembly project with version 0.29.0 and later.

By 'not work' what I observered is that the result of .ToHtml is an empty string. It is not null. No exceptions are thrown,

          var pipeline = new MarkdownPipelineBuilder()
            .UseAdvancedExtensions()
            .Build();
            var md = @"# Header";
            var result = Markdown.ToHtml(md, pipeline);
            Console.WriteLine(result);
            return result;

So as far as I can tell, something between 28.1 an 29.0 broke the ability for the library to function correctly within Blazor WebAssembly projects. I did review https://github.com/xoofx/markdig/compare/0.28.1...0.29.0 but nothing there jumped out at me as an obvious culprit.

Unfortunately its not that easy to debug .Net code running as WASM in a browser, so I am running up against my ability to work out what is going on here. I did attempt to set the Builder's DebugLog to Console.Out, to see if that would get me anything, but then a code search has turned up that almost nothing writes to DebugLog.

At the moment, I will be forced to stay on 0.28.1.

Originally created by @wleader on GitHub (Apr 22, 2022). I was testing with some very simple code and I have observed the following: This code does work in a .Net 6.0 Console application with version 0.29.0 & 0.28.1 This code does work in a .Net 6.0 Blazor Web Assembly project with version 0.28.1 and several earlier versions (28.0, 27.0, 22.0). This code does not work in a .Net 6.0 Blazor Web Assembly project with version 0.29.0 and later. By 'not work' what I observered is that the result of .ToHtml is an empty string. It is not null. No exceptions are thrown, var pipeline = new MarkdownPipelineBuilder() .UseAdvancedExtensions() .Build(); var md = @"# Header"; var result = Markdown.ToHtml(md, pipeline); Console.WriteLine(result); return result; So as far as I can tell, something between 28.1 an 29.0 broke the ability for the library to function correctly within Blazor WebAssembly projects. I did review https://github.com/xoofx/markdig/compare/0.28.1...0.29.0 but nothing there jumped out at me as an obvious culprit. Unfortunately its not that easy to debug .Net code running as WASM in a browser, so I am running up against my ability to work out what is going on here. I did attempt to set the Builder's DebugLog to Console.Out, to see if that would get me anything, but then a code search has turned up that almost nothing writes to DebugLog. At the moment, I will be forced to stay on 0.28.1.
claunia added the bug label 2026-01-29 14:38:58 +00:00
Author
Owner

@MihaZupan commented on GitHub (Apr 22, 2022):

Among those changes, my guess is it's something about #621. I'll have to dig in to find out which change doesn't like WASM.

@MihaZupan commented on GitHub (Apr 22, 2022): Among those changes, my guess is it's something about #621. I'll have to dig in to find out which change doesn't like WASM.
Author
Owner

@MihaZupan commented on GitHub (Apr 22, 2022):

It is indeed 76e25833ad.
Specifically
b32e71aaeb/src/Markdig/Renderers/RendererBase.cs (L183-L184)

The MT pointer (or whatever that memory is in WASM) appears to be always 0.

@MihaZupan commented on GitHub (Apr 22, 2022): It is indeed 76e25833ad9031c5c36e79b7aac60232ef8448ee. Specifically https://github.com/xoofx/markdig/blob/b32e71aaeb81c85a6038a179429e387c93e1359a/src/Markdig/Renderers/RendererBase.cs#L183-L184 The MT pointer (or whatever that memory is in WASM) appears to be always 0.
Author
Owner

@RayWangQvQ commented on GitHub (Apr 23, 2022):

Version 0.30.1 has the same problem:
image

Hope it can be fixed as soon as possible.

BTW, I don't understand why such an obvious bug would be exposed to the release.
Since many WASM projects recommend using markdig, I wonder if WASM testing can be added to the test standard in the future to avoid similar bugs.

@RayWangQvQ commented on GitHub (Apr 23, 2022): Version `0.30.1` has the same problem: ![image](https://user-images.githubusercontent.com/31154238/164866438-5813539b-2d33-46f8-aacb-38968a9b0724.png) Hope it can be fixed as soon as possible. BTW, I don't understand why such an obvious bug would be exposed to the release. Since many WASM projects recommend using markdig, I wonder if WASM testing can be added to the test standard in the future to avoid similar bugs.
Author
Owner

@xoofx commented on GitHub (Apr 23, 2022):

BTW, I don't understand why such an obvious bug would be exposed to the release.
Since many WASM projects recommend using markdig, I wonder if WASM testing can be added to the test standard in the future to avoid similar bugs.

I didn't know that markdig was used in the context of WASM 😅
So feel free to make a PR. At work we had to add WASM testing for a complete different project and that was quite a work and struggle. If with Blazor that's easy, then you are welcome.

@xoofx commented on GitHub (Apr 23, 2022): > BTW, I don't understand why such an obvious bug would be exposed to the release. > Since many WASM projects recommend using markdig, I wonder if WASM testing can be added to the test standard in the future to avoid similar bugs. I didn't know that markdig was used in the context of WASM 😅 So feel free to make a PR. At work we had to add WASM testing for a complete different project and that was quite a work and struggle. If with Blazor that's easy, then you are welcome.
Author
Owner

@xoofx commented on GitHub (Apr 23, 2022):

0.30.2 was just released and should fix this problem.

@xoofx commented on GitHub (Apr 23, 2022): `0.30.2` was just released and should fix this problem.
Author
Owner

@NickPolyder commented on GitHub (Jun 11, 2023):

Hello @xoofx,
I have the version 0.31.0 and it still appears to be the same issue for me.

thats what I have

private static readonly MarkdownPipeline DefaultMarkdown = new MarkdownPipelineBuilder()
		.UseAdvancedExtensions()
		.Build();

return (MarkupString) Markdown.ToHtml(rawMarkdown, DefaultMarkdown)
@NickPolyder commented on GitHub (Jun 11, 2023): Hello @xoofx, I have the version `0.31.0` and it still appears to be the same issue for me. thats what I have ```cs private static readonly MarkdownPipeline DefaultMarkdown = new MarkdownPipelineBuilder() .UseAdvancedExtensions() .Build(); return (MarkupString) Markdown.ToHtml(rawMarkdown, DefaultMarkdown) ```
Author
Owner

@xoofx commented on GitHub (Jun 11, 2023):

I have the version 0.31.0 and it still appears to be the same issue for me.

Open a new issue. It might be a different problem. Personally, won't have time to investigate.

@xoofx commented on GitHub (Jun 11, 2023): > I have the version 0.31.0 and it still appears to be the same issue for me. Open a new issue. It might be a different problem. Personally, won't have time to investigate.
Author
Owner

@NickPolyder commented on GitHub (Jun 11, 2023):

Thank you for the quick response @xoofx.
Actually after a lot of research I found out that the reason that it was not working was the header of the file that I was reading it from.

It had a header of \uFEFF which is the byte array { 239, 187, 191 } and it appears to be for utf8 files and that was making the whole first line to not be able to be parsed.

I dont know if there is any place you would like me to post this for the next person to find or if there is a documentation that I could post it in case someone else has the same issue.

Best,

@NickPolyder commented on GitHub (Jun 11, 2023): Thank you for the quick response @xoofx. Actually after a lot of research I found out that the reason that it was not working was the header of the file that I was reading it from. It had a header of `\uFEFF` which is the byte array `{ 239, 187, 191 }` and it appears to be for utf8 files and that was making the whole first line to not be able to be parsed. I dont know if there is any place you would like me to post this for the next person to find or if there is a documentation that I could post it in case someone else has the same issue. Best,
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/markdig#534