A workaround is to set the table element's height as well:
<telerik:RadEditor runat="server" ID="RadEditor1" Height="400">
</telerik:RadEditor>
<telerik:RadButton runat="server" ID="RadBtn1" AutoPostBack="false"
Text="Change Size" OnClientClicked="changeEditorSize"></telerik:RadButton>
<script type="text/javascript">
function changeEditorSize(sender, args) {
var editor = $find("<%= RadEditor1.ClientID %>");
var width = editor.get_element().style.width;
editor.setSize(width, "200px");
//this line is the workaround
editor.get_mainTable().style.height = "200px";
}
</script>
A page which exhibits the error is included below. I have a ticket open with Chromium as well: https://code.google.com/p/chromium/issues/detail?id=412772&thanks=412772&ts=1410359622 Problematic page: http://imodblue.imodules.com/s/1197/social.aspx?sid=1197&gid=1&pgid=2219&content_id=1815 (click the Registration button) Only crashes when the RadEditor is referenced on the page, even if it remains hidden. I'm working on trying to strip it down to a simpler example, but maybe the full page is enough for you guys to help me diagnose it. We are on an older version in production, 2012.3.1023.35. The crash was reproducible with version 2014.2.724.45, but there's no public site with that version that I can use as an example.
If an anchor is added in the content of a RadEditor, the control is switched in Preview mode and a postback is executed, onclick="return false;" and target="blank" will be inserted in the anchor under IE. In case these attributes are already set, they will be renamed to re_onclick and re_target and the attributes mentioned above will be inserted again.
Steps to reproduce:
1. Create StyleSheet.css file containing the following style:
p { color: red; }
2. Set the following markup:
<telerik:RadWindow ID="RadWindow1" runat="server" VisibleOnPageLoad="true">
<ContentTemplate>
<telerik:RadEditor ID="RadEditor1" runat="server">
<CssFiles>
<telerik:EditorCssFile Value="StyleSheet.css" />
</CssFiles>
<Content>
<p>test</p>
<p>test</p>
</Content>
</telerik:RadEditor>
</ContentTemplate>
</telerik:RadWindow>
3. Make sure RadEditor's EditorCssFile property points to the created StyleSheet.css file
Result: The red color is not applied to the paragraphs in the content area.
Workaround:
<script>
(function (utils) {
var addStyleSheet = utils.addStyleSheet;
utils.addStyleSheet = function (url, doc, id) {
if ($telerik.isFirefox) {
if (!url) return;
doc = doc || document;
var link = doc.createElement("link");
link.setAttribute("href", url, 0);
link.setAttribute("type", "text/css");
link.setAttribute("rel", "stylesheet", 0);
if (id) link.setAttribute("id", id);
var headElement = doc.getElementsByTagName("head")[0];
var addSheet = function () { headElement.appendChild(link); };
window.setTimeout(addSheet, 200);
}
else {
addStyleSheet.call(this, url, doc, id);
}
}
})(Telerik.Web.UI.Editor.Utils);
</script>
Newly created areas in the ImageMapEditor dialog cannot be modified and controlled properly by end-users.
This issue is causing inconvenient experience when the new line mode is set to add paragraphs and the cursor is set right after the link element.
When the Editor is used in Right to Left mode, the modules at the bottom of the control are not properly positioned and the resizing handler does not point to the right direction - http://screencast.com/t/JwPlpE3zPDzi
Due to initial invalid content the Editor's ConvertToXhtml filter throws a JS error that breaks the further initialization of the control.
A possible resolution is incorporating the following sample code:
<telerik:RadEditor runat="server" ID="RadEditor1" OnClientLoad="OnClientLoad">
</telerik:RadEditor>
<script type="text/javascript">
Telerik.Web.UI.Editor.NestedElementsFix.prototype._getLastInvalidWrapper = function (node) {
var parent = node;
while (parent.parentNode && this._shouldUnwrapNode(parent.parentNode)) {
parent = parent.parentNode;
}
return parent == node ? null : parent;
}
function OnClientLoad(editor, args) {
editor.set_html(editor.get_html(true));
}
</script>
User is able to add this to the radeditor with allowscripts=false...granted not a script but CLEARLY gaming the system. It shouldn't be up to us to write custom filters to handle these things, it should be native and tested in the editor itself. <h1>TROLOLOLOLOLOL</h1><meta http-equiv="refresh" content="1;url=http://bit.ly/1bJjrjr" /> <fk></fk>
This method is used to fix some layout issues of the editor. For each call of this method, the editors content grows with one BR element. Due to that the content area is getting with additional lines.
A possible resolution is incorporating the following override that fixes the onParentNodeChanged method:
<telerik:RadEditor runat="server" ID="RadEditor1">
</telerik:RadEditor>
<script type="text/javascript">
var oldOnParentNodeChanged = Telerik.Web.UI.RadEditor.prototype.onParentNodeChanged;
Telerik.Web.UI.RadEditor.prototype.onParentNodeChanged = function () {
oldOnParentNodeChanged.call(this);
if (this.get_filtersManager().getFilterByName("MozillaRemoveLastBr")) {
this.get_filtersManager().getFilterByName("MozillaRemoveLastBr").getHtmlContent(this.get_contentArea());
}
};
</script>
'Accept All' and 'Reject All' track changes buttons stay enabled if CanAcceptTrackChanges="false". At the same time Accept and Reject buttons are properly disabled.
The behavior is observed both with ToolbarMode set to "Default" and to "Ribbonbar".
A temporarily workaround for ToolbarMode='Default' is:
<telerik:RadEditor ID="theEditor" EnableTrackChanges="true" runat="server"
OnClientLoad="OnClientLoad" OnClientSelectionChange="OnClientSelectionChange" >
<Tools>
<telerik:EditorToolGroup>
<telerik:EditorTool Name="AcceptTrackChange" Text="Accept" />
<telerik:EditorTool Name="RejectTrackChange" Text="Reject" />
<telerik:EditorTool Name="AcceptAllTrackChanges" Text="Accept All" />
<telerik:EditorTool Name="RejectAllTrackChanges" Text="Reject All" />
<telerik:EditorTool Name="EnableTrackChangesOverride" Text="Enable Track Changes Override" />
</telerik:EditorToolGroup>
</Tools>
<TrackChangesSettings CanAcceptTrackChanges="false">
</TrackChangesSettings>
<Content>
<strong title="Formatted by RadEditorUser on Tuesday, May 08, 2012 5:59:11 PM" class="reFormat reU0" author="RadEditorUser" timestamp="1336489151795" browsercommand="Bold">RadEditor</strong>
</Content>
</telerik:RadEditor>
<script type="text/javascript">
function OnClientLoad(editor, args) {
if (!editor.get_canAcceptTrackChanges()) {
editor.get_toolAdapter().getToolByName("RejectAllTrackChanges").set_enabled(false);
editor.get_toolAdapter().getToolByName("AcceptAllTrackChanges").set_enabled(false);
}
}
function OnClientSelectionChange(editor, args) {
if (!editor.get_canAcceptTrackChanges()) {
setTimeout(function () {
editor.get_toolAdapter().getToolByName("RejectAllTrackChanges").set_enabled(false);
editor.get_toolAdapter().getToolByName("AcceptAllTrackChanges").set_enabled(false);
}, 0);
}
}
</script>
A workaround for ToolbarMode='Ribbonbar' is setting the following style:
.rrbDisabled, .AcceptTrackChange, .RejectTrackChange
{
opacity: .45;
}
This issue causes an annoying flickering of the page and inconvenient typing experience of the user.
If you create a link with a target="_blank" attribute, the corresponding value shows as selected. When the Link Manager is opened second time the value shows as selected, but the link is not set without a target attribute. You can find attached a sample project, in which is used the Custom Built-In dialogs approach to resolve the problem. For details about this approach follow this link: http://demos.telerik.com/aspnet-ajax/editor/examples/externaldialogspath/defaultcs.aspx
The tools are not respected by the toolgroups under IE7 and IE7 standards. This issue causes incorrect layout at resizing and overlay issues of floated tools.
The problem is introduced because the toolgroup elements does not have a properly set width.
Possible resolution is setting a proper width to every UL at the load event of the editor:
<telerik:RadEditor runat="server" ID="RadEditor1"
OnClientLoad="OnClientLoad"></telerik:RadEditor>
<script type="text/javascript">
function OnClientLoad(editor, args) {
if (editor.isVisible()) {
fixToolbarsInIE(editor);
} else {
editor.add_firstShow(function () {
setTimeout(function () {
fixToolbarsInIE(editor);
}, 0);
})
}
}
function fixToolbarsInIE(editor) {
if ($telerik.isIE) {
var $ = $telerik.$;
var editorID = editor.get_id();
var topTD = document.getElementById(editorID + "Top");
var toolGroupElements = $(topTD).find(".reToolbar");
for (var i = 0, l = toolGroupElements.length; i < l; i++) {
calculateTools(toolGroupElements[i]);
}
}
}
function calculateTools(toolGroup) {
var tools = toolGroup.children;
var size = 0;
for (var i = 0, l = tools.length; i < l; i++) {
var tool = tools[i];
size += tool.offsetWidth;
}
toolGroup.style.width = size + "px";
}
</script>
The mentioned delete operations are not working as expected and consistent across the major browsers. This behavior is casing the Track Changes feature to be unavailable and unusable in some cases.
RadEditor's content is messing up when links are generated through document manager and submit it from Preview mode. The issue is reproducible in Internet Explorer 7
However, a possible workaround for the issue would be to set the following code the OnClientSubmit event of the RadEditor:
<telerik:RadEditor OnClientSubmit = "OnClientSubmit" />
<script>
function OnClientSubmit(editor)
{
editor.set_mode(1); //Force design mode
}
</script>
Inline commands such as bold, italic, underline doesn't trigger each time with empty selection in Internet Explorer.
The paste functionality in RadEditor does not work when EnableTrackChanges property is set to true. This behavior is observed under Chrome and Safari.
When text is pasted in RadEditor with ContentAreaMode="Div" under Firefox and Chrome, the cursor will be positioned before the pasted text.