At present, when a RadWindow is pinned, it still uses position: absolute and an interval is initiated to recalculate its position every 100ms. This causes it to visibly "jump" when the user scrolls the page because of the interval update in its location.

Instead, position: fixed should be used to avoid the position calculation on an interval.

In Q3 2013 the script that creates the modal background for our dialogs (e.g., RadAlert, RadConfirm) was improved with the following:
- some issues that allowed focus to get to the background were fixed
- accessKey handling was improved
- an option was added to set the disabled attribute of elements the developer chooses
- tabIndex recognition was improved (the key problem is that if the attribute is not set, no two browsers return the same or proper information)

Since these scripts now do a lot more work, huge pages can experience a slowdown when a modal dialog is shown. For example, a page with about 7000 elements took about 800ms vs about 70ms with the old scripts for the same page.

The performance can be improved by adding the attached script (a minified version of the old code) to the end of the page. You can add it as a script reference, or simply copy it inline, depending on your preferences. Using this script will, however, remove the fixes and improvements done in Q3 2013, as well as any other modifications we make in the future.

If a performance improvement in the scripts is possible, it will speed up the process (probably not all the way to the previous levels) without losing the new functionality.

After added this code window close button stop working.

if we remove these three properties it works fine
        oWnd.SetWidth(width);
        oWnd.SetHeight(height);
        oWnd.center();


function openWin(url) {
        var oWnd = radopen(url, "RadWindow22");
        oWnd.SetWidth(width);
        oWnd.SetHeight(height);
        oWnd.center();
    }

It should be similar to the RadAjaxManager.GetCurrent(Page) method and return the first RadWindowManager instance on the page. Note that, unlike most other manager type controls there may be multiple RadWindowManagers on the page in a valid scenario.

Currently setSize() works for popups that are already shown. If setSize() is called before show() (or radopen() or open() from a RadWindowManager) the new size will not be respected on subsequent iterations.

Allow adding buttons near cancel button rather than inside form. Please see attachments.

This is related to a browser bug in accessing the document.activeElement property inside an iframe under IE9 and IE10.

See this KB article for additional information and examples: http://www.telerik.com/support/kb/aspnet-ajax/window/modal-radwindow-in-radwindow-in-ie9-and-ie10.aspx .

There are several possible workarounds:
1) remove the Modal feature.
2) Replace the opening logic with the one from this thread ( http://www.telerik.com/community/forums/aspnet-ajax/window/opening-radwindow-from-the-server.aspx ) and add a small timeout before showing the RadWindow. Even 0ms could suffice so the browser has an active element
3) Replace the RadAjaxPanel with an ASP UpdatePanel with UpdateMode set to Conditional
4) Add a function that will provide a focused element and call it in the OnClientBeforeShow event of the RadWindow
5) Add that function and call it in the ResponseScripts of the RadAjaxPanel
 The function could look like this: function fixIE() { document.documentElement.focus();} where, of course, you can focus some other element on the page.

A sample is attached.

Currently the video does not play, only audio is heard. If autosizing is disabled the video functions properly.
A possible workaround is to disable autosizing and manually call the autosize() method when the page is loaded for all other browsers:

<telerik:RadWindow runat="server" ID="rw1" VisibleOnPageLoad="true" NavigateUrl="PlayVideo.aspx"
    AutoSize="false" Width="700" Height="500" OnClientPageLoad="OnClientPageLoad">
</telerik:RadWindow>

 and

function OnClientPageLoad(sender, args)
{
    setTimeout(function ()
    {
        if (!$telerik.isMobileSafari)
        {
            sender.autoSize(false);
        }
    }, 0);
}

Instead, the dimensions the popup will have when restored are returned. This is so because a maximized RadWindow will resize with the browser.

A possible workaround is using the Telerik Static Client Library: http://www.telerik.com/help/aspnet-ajax/telerik-static-client-library.html

			var wnd = $find("RadWindow1");
			wnd.maximize();
			var bounds = $telerik.getBounds(wnd.get_popupElement());
			alert(bounds.width);

With the classic render mode this allows the developer to always position the popup according to a given target with a given offset.
With the lightweight render mode the current bounds are returned instead of the offsets set by the developer.

The following example always shows a RadWindow according to its offset element instead of only the first time:
						oWindow = $find("<%=winTest2.ClientID%>");
						oWindow.show();
						if (oWindow.get_offsetElementID())
						{
							offsetElementBounds = $telerik.getBounds($get(oWindow.get_offsetElementID()));
							oWindow.moveTo(offsetElementBounds.x + oWindow.get_left(), offsetElementBounds.y + oWindow.get_top());
						}
This will not work as expected with the Lightweight render mode, because the popup will move additionally with its width and height.

The issue does not manifest with iOS9 or the Classic RenderMode

To get the RadWindow to center properly, you need to use its OnClientAutoSizeEnd event and  call its center() method:

This issue affects only the Q1 2016 SP1 release.

		<script>
			function OnClientAutoSizeEnd(sender, args) {
				sender.center();
			}
		</script>
		<telerik:RadWindow ID="RadWindow1" runat="server" OpenerElementID="Button1" AutoSize="true" Modal="true" OnClientAutoSizeEnd="OnClientAutoSizeEnd">
			<ContentTemplate>
				<div style="width: 600px; height: 400px; background: yellow;">dummy content for autosizing</div>
			</ContentTemplate>
		</telerik:RadWindow>
		<asp:Button ID="Button1" Text="open RW" runat="server" />

When a RestrictionZone is used, under Chrome for iOS7, the first time an input inside a RadWindow is tapped it cannot get focus. This means that its onfocus event does not fire and the user cannot type in it even though the keyboard was shown.
When another input is focused things start working properly.
A way to avoid this is to remove the RestrictionZone property.
You can also remove the restriction zone for mobile devices to include chrome
		function OnClientShow(sender, args)
		{
			if ($telerik.isTouchDevice)
			{
				sender.set_restrictionZoneID("");
			}
		}

For the time being you can use the following CSS workaround:
	<telerik:RadCodeBlock ID="RadCodeBlock1" runat="server">
		<style>
		html .RadWindow_Bootstrap.rwLoading .rwExternalContent {
			background-image: url('	<%= Telerik.Web.SkinRegistrar.GetWebResourceUrl(this, typeof(RadWindow), "Telerik.Web.UI.Skins.Bootstrap.Common.loading.gif") %>')
		}
	</style>
	</telerik:RadCodeBlock>

The WAI-ARIA specification indicates that there are alert, alertdialog and dialog roles, the appropriate one must be applied to the RadWindow dialogs.
http://www.w3.org/TR/wai-aria/roles#alert
http://www.w3.org/TR/wai-aria/roles#alertdialog
http://www.w3.org/TR/wai-aria/roles#dialog

In the meantime, you can use a script like this to apply the role:
        <script type="text/javascript">
            function OnClientShow(sender, args) {
                var role = "dialog";
                 if (sender._isPredefined) { //this captures RadAlert, RadConfirm and RadPrompt
                   role = "alertdialog"; 
                }
                //this will be executed for all child RadWIndows from that manager so you can apply a different role (e.g., dialog)
               sender.get_popupElement().setAttribute("role", role);
            }
        </script>

        <telerik:RadWindowManager runat="server" ID="RadWindowManager1" EnableAriaSupport="true" OnClientShow="OnClientShow"></telerik:RadWindowManager>


Note: Testing with the JAWS screen reader indicates that it does not recognize dynamically created HTML, and all RadWindow dialogs are created dynamically with JavaScript. This is a shortcoming of the reader.