Why not keeping Window element in the original DOM position?

[Hugo Augusto]

RadWindow is a great control and it's very usefull.

The issues start when the UI inside gets more complex, and requires javascript to deal with interactions on client side instead of server side.

The RadWindow control is placed inside a parent element but when it opens, all the contents get relocated into the DOM root causing a problem with event listeners, element finding among other headaches.

Testing with your Telerik Web UI Window Content Template Demo | Telerik UI for ASP.NET AJAX demo, moving the generated window element "RadWindowWrapper_ctl00_ContentPlaceholder1_UserListDialog" inside its original element  "demo-container", kept the demo working perfectly with no side effects.

So, the question is, why are you moving the contents of a RadWindow to the DOM root causing so many problems for those who need to create complex UIs inside the window? Can't you at least let the developer decide that with a parameter? 

Is there any way to avoid this behaviour, maybe using javascript?

Thank you.

 

[Rumen]

Hi Hugo,

Thanks for the detailed explanation and for testing things on your side.

The current behavior is intentional and has been part of RadWindow's architecture for a long time. It is not an arbitrary design choice but one that addresses several constraints that appear in real-world applications. Changing it today would break many existing setups that rely on the current rendering logic.

The main issue is CSS stacking context. If RadWindow stays nested inside your container, any parent with position: relative, overflow: hidden, or even something like transform or filter will mess with the window's z-index and positioning. We've seen cases where the window gets clipped, hidden behind other elements, or simply won't display correctly. Moving it to the form root avoids all of that.

For modal windows specifically, the overlay needs to cover the entire page. That's pretty much impossible if the window element is buried deep in the DOM tree.

There's also the AJAX scenario - if your RadWindow is inside an UpdatePanel and that panel refreshes, the whole window (along with its state) can get wiped out or duplicated.

Regarding your test in the demo: moving the wrapper back into the original container works in simple scenarios, but issues typically surface in more complex layouts that include AJAX, multiple dialogs, stacked modals, custom CSS rules, or MinimizeZone usage. These are the cases the current design was built to handle reliably.

What you can do instead:

• Use event delegation instead of attaching listeners directly to elements inside the window
• Access elements through RadWindow.get_contentElement() as your root reference
• For server controls in ContentTemplate, use $find() with the ClientID

I understand the desire for a parameter to control this behavior, but supporting both modes would require significant changes to the component's internals and would introduce a large set of edge cases for existing applications.

If you are facing a specific interaction issue inside the window, feel free to share the scenario and we can suggest a precise workaround.

 

Regards,
Rumen
Progress Telerik