Markdown RichTextEditor in Modal SfDialog renders incorrectly.

When using an SfRichTextEditor in Markdown Editor Mode inside of a SfDialog where IsModal is 'true', the height of the RTE does not render properly. I make calls to rteObj.RefreshUIAsync() in both the Created callback for the RTE and the Opened callback of the dialog, to no avail. When in Markup mode, the issue is not present.


The issue is reproduced in the following Syncfusion playground.


Please provide any insight as to how I can resolve this issue.


Thank you.


11 Replies

BT Bhuvaneshwari Thirunavukarasu Syncfusion Team March 7, 2025 12:44 PM UTC

Hi Hunter Malley,

Thank you for reaching out.

We have reviewed your query and found that the issue does not occur in our local environment but is reproducible in the online playground sample. This may be due to the editor's height being calculated before the dialog opens.


To resolve this, we recommend explicitly setting the Height property of the SfRichTextEditor.

Screenshot Reference:


Sample Link: https://blazorplayground.syncfusion.com/rjhoNqDQJIPNxLcy

Could you please try this solution and let us know if the issue persists?

Looking forward to your response.

Thanks,

Bhuvaneshwari T



HM Hunter Malley March 10, 2025 04:18 PM UTC

Thank you for your response.


I am looking to use the component to display content of varying heights and therefore do not want to set the height as a literal. Is there no way to have the height be calculated dynamically and be responsive? I assumed the calls to RefreshUIAsync() in the RTE Created() and Dialogue Opened() callbacks would recalculate the height.


Best,

Hunter




BT Bhuvaneshwari Thirunavukarasu Syncfusion Team March 11, 2025 08:41 AM UTC

Hi Hunter Malley,

As mentioned earlier, the issue does not occur in our local environment but is reproducible only in the online playground sample.

For your reference, we have attached the sample and a screenshot.


Could you please check this in your local environment and let us know if the issue is replicated locally?

Thanks,
Bhuvaneshwari T


Attachment: BlazorRTE_f7218a07.zip


HM Hunter Malley March 11, 2025 01:09 PM UTC

Good morning,


Thank you for including that sample. In the sample, it looks like a using statement for Syncfusion.Blazor.Popups is not included in the _Imports.razor. After adding that line so the content is actually presented in a Dialogue component, the issue is replicated for me locally. 


Is the issue replicated locally, on your end, when the Dialogue component is properly set up?


Best,

Hunter



HM Hunter Malley March 14, 2025 02:02 PM UTC

Hello,


I am just following up on this issue.


Best,

Hunter



BT Bhuvaneshwari Thirunavukarasu Syncfusion Team March 17, 2025 11:16 AM UTC

Hi Hunter Malley,
Thank you for your patience and for providing additional details.
We have reviewed your query and were able to reproduce the issue locally after adding Syncfusion.Blazor.Popups to the _Imports.razor file.
As a workaround, we recommend using the DialogOpen event to dynamically adjust the height by calling a JavaScript interop function. You can implement this as follows:
1. Invoke the JavaScript function inside the DialogOpen event in Blazor:
await JS.InvokeVoidAsync("adjustTextareaHeight", "benefits_editable-content");
2. Add the JavaScript function:
In your wwwroot/js/site.js (or any JavaScript file included in your Blazor project), add the following:
window.adjustTextareaHeight = (textareaId) => {
    let textarea = document.getElementById(textareaId);
    if (textarea) {
        textarea.style.height = "auto"; // Reset height to recalculate
        textarea.style.height = textarea.scrollHeight + "px"; // Set new height
    }
};
3. Ensure your JavaScript file is registered
Include your JavaScript file in the <head> section of index.html (for Blazor WebAssembly) or _Host.cshtml (for Blazor Server).
We have attached a sample project demonstrating this solution for your reference.

Screenshot reference:


Please try it and let us know if you need further assistance.
Best regards,
Bhuvaneshwari Thirunavukarasu



Attachment: BlazorRTE_a8496435.zip


HM Hunter Malley March 17, 2025 12:25 PM UTC

Thank you very much for providing that work around.


While that solution works, appropriately resizing the RTE on dialog open, it causes the form to be a bit jumpy when opened. The element first has the default height, and then jumps down to the correct, calculated height. 


Are there any plans to address this issue with the SfRichTextEditor in Markdown mode in a future patch?


Best,

Hunter



BT Bhuvaneshwari Thirunavukarasu Syncfusion Team March 18, 2025 11:38 AM UTC

Hi Hunter Malley,
We have considered the reported issue "Markdown RichTextEditor in Modal SfDialog Renders Incorrectly " as a bug from our end. The fix will be included in our upcoming patch release, which is scheduled for the first week of April.


Now you can track the status of the reported issue through this feedback,

 
Disclaimer: “Inclusion of this solution in the weekly release may change due to other factors including but not limited to QA checks and works reprioritization.”
 
Thanks,
Bhuvaneshwari T


BT Bhuvaneshwari Thirunavukarasu Syncfusion Team April 2, 2025 04:18 AM UTC

Hi Hunter Malley,
Query: Markdown RichTextEditor in Modal SfDialog Renders Incorrectly 
 
We have included the fix for the issue "Markdown RichTextEditor in Modal SfDialog Renders Incorrectly " with our package version 29.1.35. So, can you please upgrade your package to the latest to resolve the issue from your end?

Root cause: For markdown editor, we are setting the height manually by calculating the scroll height but when it rendered inside the dialog rte is not in the dom, height calculation will be zero
 
Regards
Bhuvaneshwari T


BT Bhuvaneshwari Thirunavukarasu Syncfusion Team June 18, 2025 11:03 AM UTC

Hi Hunter,

Thank you for reaching out.

In Markdown mode, the Rich Text Editor is rendered as a <textarea>, and its height is not automatically calculated. The height is determined based on the scroll height, which becomes available only after the element is appended to the DOM.

When the editor is placed inside a dialog, it is usually rendered before the dialog opens. Since the editor is not yet appended to the DOM at that point, its scroll height is zero. This causes the jumpy behavior you observed, where the editor resizes after the dialog is displayed.

To resolve this, we recommend initializing the Rich Text Editor only after the dialog has fully opened. This ensures that the editor calculates its height correctly and avoids visual flicker. In the example below, the editor is conditionally rendered based on a flag set in the DialogOpenedHandler:

<SfDialog ShowCloseIcon="true" AllowPrerender="true" IsModal="true" CssClass="wtbi-modal" ZIndex="200000">
    <DialogEvents OnOpen="@DialogOpenedHandler"></DialogEvents>
    <DialogTemplates>
        <Header>Details</Header>
        <Content>
            <div id="details-target" class="h-100">
                @if (isDropDownOpen)
                {
                    <SfRichTextEditor id="benefits" @ref="@BenefitsRteComponent" @bind-Value="@Benefit" EditorMode="EditorMode.Markdown">
                        <RichTextEditorEvents Created="@OnBenefitsRteCreated"></RichTextEditorEvents>
                        <RichTextEditorToolbarSettings></RichTextEditorToolbarSettings>
                    </SfRichTextEditor>
                }
            </div>
        </Content>
    </DialogTemplates>
</SfDialog>

@code {
    public bool isDropDownOpen { get; set; } = false;
    public SfRichTextEditor BenefitsRteComponent { get; set; }

    public async Task DialogOpenedHandler()
    {
        isDropDownOpen = true;
    }
}

We've also attached a sample and screen recording for your reference.


We appreciate your feedback and will consider this behavior for improvement in a future update.

Best regards,
Bhuvaneshwari T


Attachment: BlazorRTE_4ad407fc.zip


BT Bhuvaneshwari Thirunavukarasu Syncfusion Team June 19, 2025 05:14 AM UTC

Hi Hunter,
Thank you for getting back to us, and we appreciate your patience.
Query 2:
We were able to reproduce the issue in the Blazor Playground when simulating a mobile device before initializing the component. However, this issue does not replicate in a local environment.
We observed that the dialog component is not rendering correctly in mobile mode due to height constraints when rendered based on the body element. In such scenarios, if the dialog's content height exceeds the body height, it may result in layout issues or runtime exceptions.
To resolve this, please apply the following CSS to ensure the body occupies the full height of the viewport:
html, body {    height: 100%; }
This adjustment ensures the dialog height is calculated correctly in both desktop and mobile views.
If you continue to face any issues after applying these changes or once the patch is released, please let us know. We’re here to assist you further.
Best regards,
Bhuvaneshwari T

Loader.
Up arrow icon