When a large page is scrolled to the target element, the tooltip is placed higher than expected.

Possible workaround is to use RelativeTo="Element" property.

Problem:

With the latest version of Google Chrome 61 the tooltip is not positioning correctly when the page is scrolled down.

Details: 

The tooltip positioning problem is due to the following breaking change in Chrome 61 (see release notes at https://blog.chromium.org/2017/08/chrome-61-beta-javascript-modules.html):

To align with the spec and preserve browser consistency, the scrollingElement is now the documentElement in standards mode.
Chrome 61 has changed the behavior of document.scrollingElement to return document.documentElement instead of document.body to match the CSSOM View specification and this broke the positioning of the tooltip.

Solution:

Use the _getPosRelativeToMouse override to solve the problem:

<telerik:RadGrid ID="RadGrid" runat="server"></telerik:RadGrid>
<telerik:RadToolTipManager ID="RadToolTipManager1" AutoTooltipify="true" runat="server">
</telerik:RadToolTipManager>
   Telerik.Web.UI.RadToolTip.prototype._getPosRelativeToMouse = function(targetBounds) {
                 var elemX = targetBounds.x;
                 var elemY = targetBounds.y;

                 //Get last recorded mouse position
                 var pos = this._getMousePosition();
                 var mouseX = pos.clientX;
                 var mouseY = pos.clientY;

                 //Take into consideration the offsetScroll!
                 var standard = $telerik.standardsMode;
                 //$telerik.standardsMode does not do a good job! Extra check is needed for FF!!
                 //And yet another check needed for Safari! It should always be set to false in order to get the calculations right
                 if (!$telerik.isIE && document.compatMode != "CSS1Compat") standard = false;
                 else if (($telerik.isSafari && !(Telerik.Web.Browser.chrome && Telerik.Web.Browser.version >= 61)) || (Telerik.Web.Browser.edge && Telerik.Web.Browser.version >= 15)) standard = false;

                 if (standard) {
                     elemX -= $telerik.getCorrectScrollLeft(document.documentElement);
                     elemY -= document.documentElement.scrollTop;
                 }
                 else //NEW: Add support for quircksmode
                 {
                     elemX -= $telerik.getCorrectScrollLeft(document.body);
                     elemY -= document.body.scrollTop;
                 }

                 //Calculate the position of the mouse, relative to the targetcontrol
                 var deltaX = mouseX - elemX;
                 var deltaY = mouseY - elemY;

                 return { x: deltaX, y: deltaY };
             }

In case the color difference is a problem, you can examine the rendered Classic tooltip and find the color CSS rule that is applied, then apply it to the Lightweight mode via a CSS selector similar to the following:
		div.RadToolTip_Simple .rtContent
		{
			color: #C98400;
		}
Where you can change Simple with the skin name that you are using.

The ContentScrolling property does not take effect under IE10. The end result is that the control behaves as if the property has its Default value (i.e. the browser will handle the overflow of the elements, which means large content will stretch the tooltips).

When Tooltip ContentScrolling property is set to Auto the the tooltip dimensions are not computed properly and the layout looks inconsistent (i.e. usually the left and/or right borders are missing).

Possible workarounds are:

1) using content that will fit in the tooltip and leaving the ContentScrolling property to its default value

OR

2) using some JavaScript to modify the dimensions:
function OnClientResponseEnd()
{
	var activeTooltip = Telerik.Web.UI.RadToolTip.getCurrent();
	if (activeTooltip)
	{
		var contentElement = activeTooltip.get_contentElement();
		if (contentElement)
		{
			contentElement.style.width = parseInt(contentElement.style.width) - 15 + "px";
			contentElement.style.height = parseInt(contentElement.style.height) - 15 + "px";
			contentElement.style.overflow = "auto";
		}
	}
}

where this is attached to the OnClientResponseEnd event of the RadToolTipManager.

A possible workaround is to recalculate the positions in the OnClientShow event. Here is an example for the BottomCenter position

					<script>
						function repositionCallout(sender, args) {
							var callout = $telerik.$(".rtCallout.rtCalloutTopCenter", sender.get_popupElement());
							if (callout.length > 0) { //there is a callout and its position is in the top center (i.e., tooltip's position is BottomCenter)
								var targetPos = $telerik.getBounds(sender.get_targetControl());
								var ttipPos = $telerik.getBounds(sender.get_popupElement());
								var calloutPos = $telerik.getBounds(callout[0]);
								var desiredCalloutLeft = targetPos.x - ttipPos.x + targetPos.width / 2 - calloutPos.width / 2;
								callout.css("left", desiredCalloutLeft);
							}
						}
					</script>
					<telerik:RadToolTip ID="MainMenu" runat="server" TargetControlID="imgbtnMenuIcon" ShowEvent="OnClick" ShowDelay="0" AutoCloseDelay="0" Position="BottomCenter" RelativeTo="Element" RenderMode="Lightweight" Width="500px" Height="500px" OnClientShow="repositionCallout">
						tooltip content
					</telerik:RadToolTip>

See http://www.telerik.com/community/forums/aspnet-ajax/tooltip/changing-targetcontrol-on-the-client.aspx
It should be expected that this timeout around the public API is not needed and the problem is taken care of internally by the control.

When the tooltip is behind the modality it cannot be closed by the users. 

You can workaround this behavior by following the script below:

<telerik:RadButton runat="server" ID="RadButton1" Text="Hover"></telerik:RadButton>

<telerik:RadToolTip ID="rttAdditionalFeatures" runat="server" ManualClose="True" Modal="True"
    TargetControlID="RadButton1" ShowEvent="OnMouseOver" OnClientShow="OnClientShow">
    Some text
</telerik:RadToolTip>

<script type="text/javascript">
    function OnClientShow(sender, args) {
        var modalLayerZindex = sender._modalExtender._backgroundElement.style.zIndex;

        if (sender.get_zIndex() <= modalLayerZindex) {
            sender.get_popupElement().style.zIndex = modalLayerZindex + 1;
        }
    }
</script> 

A workaround is to force the tooltip to update its position when the content arrives (i.e., in the OnClientResponseEnd event: http://www.telerik.com/help/aspnet-ajax/tooltipmanager-client-side-on-response-end.html )

function OnClientResponseEnd(sender, args) {
    var activeTooltip = Telerik.Web.UI.RadToolTip.getCurrent();
    if (activeTooltip) {
        activeTooltip.updateLocation();
    }
}

When the following properties are set - HideEvent="LeaveToolTip" and RenderMode="LightWeight" and the mouse cursor is moved over the ToolTip in a slower motion, the tooltip itself is hidden.

A possible workaround is to add the background-color via CSS:
		div.RadToolTip.RadToolTip_Office2007,
		.RadToolTip_Office2007 div.rtContent
		{
			background-color: #d7e3f2;
		}

The workaround is to avoid the other settings (e.g., Auto). In most cases Lightweight RenderMode will suffice, the only potential issue is loss of gradients, shadows and rounded corners in IE6-8.

When the page is in RTL mode and the manual close button of the RadToolTip is hovered it changes its position slightly.