FileManager navigation tree fails to expand child nodes inside Dialog using raw JS

[Nick Shaw]

Setup: We construct ej.filemanager.FileManager via raw JS (not the Blazor wrapper) and append it inside an ej.popups.Dialog content area. The dialog opens from a button on a legacy ASP.NET WebForms page.

Symptom: The file grid renders correctly. The navigation tree shows only the root node. Clicking the chevron next to the root node fires the expected POST request to our backend, the response returns valid child folder data (verified in Network tab), but no child <li> elements are inserted into the tree DOM. The chevron rotates visually but the tree's <li> keeps the e-collapsed class.

What we've tried (none fixed it):

1. animationSettings: { effect: 'None' } on the dialog
2. refreshLayout() after first AJAX success
3. refreshFiles() after mount (throws Cannot read properties of undefined (reading 'element'))
4. Deferred FileManager creation via setTimeout post-dialog-open
5. Setting explicit path constructor option

Comparison: The same FileManager rendered via the Blazor SfFileManager wrapper (also inside a dialog) populates the tree correctly. Backend response is byte-identical between both contexts.

Question: Is there a known requirement when constructing the JS-mode FileManager inside a Dialog? Is there a config option, lifecycle hook, or initialisation step the Blazor wrapper performs that we need to replicate in raw JS?

Note: I've been testing this on Google Chrome.

[Praveen Sellappan]

Hi Nick Shaw,

Greetings from Syncfusion Support.

Query 1: FileManager navigation tree fails to expand child nodes inside Dialog using raw JS

Based on the issue you described, we prepared a local sample using the File Manager component rendered inside the Syncfusion Dialog component.

We tested the sample using the latest Syncfusion version in Microsoft Edge and Google Chrome. During our testing, we did not encounter any issues with the File Manager navigation tree, such as child nodes failing to expand inside the Dialog, as described in your report.

In the sample, the File Manager is refreshed when the Dialog is opened to ensure it properly adjusts to the Dialog’s width and height. Even with this setup, we were unable to reproduce the reported behavior on our end.

We have attached the sample for your reference. Kindly review it and check whether it aligns with your configuration and reproduces the issue.

Sample: https://stackblitz.com/edit/h6bmofds-9sc9g3gj?file=index.js

If the issue still persists, please share the following details to help us investigate further:

• Whether you are able to reproduce the issue using the attached sample
• The Syncfusion package version you are using
• The environment in which the application is tested (browser and OS)
• A video demonstrating the issue
• Any console errors observed while running the sample
• Whether you are using a Syncfusion file system provider or a custom provider
• If using the Syncfusion provider, please share the provider name
• If possible, a minimal issue-reproducible sample

These details will help us analyze the issue more effectively.

Query 2: Is there a known requirement when constructing the JS-mode FileManager inside a Dialog? Is there a config option, lifecycle hook, or initialisation step the Blazor wrapper performs that we need to replicate in raw JS?

There is no additional configuration or special initialization step required when using the JavaScript FileManager inside a Dialog compared to the Blazor wrapper.

However, please ensure the following when rendering the FileManager inside a Dialog in JS mode:

• The FileManager should be initialized or refreshed after the Dialog is opened so that it can correctly calculate its dimensions.
• Calling the refresh() method on the FileManager after the Dialog becomes visible ensures proper layout and interaction.

document.getElementById('openBtn').onclick = function() {

    dialogObj.show();

   

    filemanagerInstance.refresh();

};

 

Please review the shared details and let us know if you need any further assistance.

Regards,

Praveen Sellappan

[Dahlia Sanchez]

I’ve run into something pretty similar with Syncfusion’s JS FileManager inside dynamic containers like Dialogs, and what you’re describing (network call succeeds but DOM tree not updating) usually ends up being a lifecycle/render timing issue rather than the backend or the FileManager itself.

A couple of things that have actually made a difference in my case:

• Make sure the FileManager is initialized after the Dialog is fully rendered and visible, not just “open triggered”. In practice, using the Dialog open event (not created or beforeOpen) is more reliable.
• If the element is being injected into content, ensure it’s already attached to the DOM before calling new ej.filemanager.FileManager(...).
• Try forcing a full re-render after expansion using something like refresh() on the FileManager instance (not just layout refresh).
• In some cases, the JS version behaves differently from the Blazor wrapper because the wrapper internally triggers additional binding cycles after async folder loads—so you may need to manually trigger a dataBind() + re-query of the tree after the child data response.

One thing that also helped in a legacy WebForms setup was explicitly setting a slight delay after the expand request resolves before calling refresh logic (basically letting the DOM update queue flush before Syncfusion tries to reconcile state).

Also worth double-checking whether the FileManager is being re-initialized or partially recreated on each dialog open—that can silently break tree state handling.

Unrelated but useful reference for UI/JS tooling patterns like this: website

[Praveen Sellappan]

Hi Dahlia,

Thank you for sharing your experience and suggestion. We appreciate your input. 

Regards,
Praveen Sellappan