<br> tag added by editor when ConvertToXhtml filter is disabled - Firefox only

[Trevor]

The problem can be seen in the Telerik content filters example editor:

http://demos.telerik.com/aspnet-ajax/editor/examples/builtincontentfilters/defaultvb.aspx

steps to reproduce using Firefox:

1. delete all the content in the editor
2. uncheck ConvertToXhtml in the filter list and click Update
3. switch the editor to HTML mode

a <br> tag has been added

you can delete the tag, but it will be added again when you switch to Design mode or back to HTML mode.

You can view a screencast demonstrating the problem here:  http://screencast.com/t/qMMGMs5z6

Note that switching the editor to HTML mode is not necessary for the <br> tag to be added. In our application, we set the editor .Content property to an empty string on the server during page load. When the page is posted back, the .Content property contains the <br>.

[Ianko]

Hello Trevor,

The described behavior is normal and expected under Firefox. By default, the browser adds this BR tag automatically, so that teh user could start typing in the editable area.

One of the purposes of the ConvertToXhtml filter is to remove this BR in HTML mode and get it back inside in Design. By that, the HTML output has no BR tag, but the user is still able to select the editable area and type text. 

Regards,
Ianko
Telerik

 

 

[Trevor]

Hi Ianko,

I can't accept your calling this normal and expected.

Your editor is inserting html into our user's content. And our application has no way of knowing whether our user entered the <br> or whether the editor inserted the <br> so we cannot resolve this problem on our side.

The *why* it happens is not important to me. What I know is the problem does not occur with other browsers, and the problem does not occur in other Editors (TinyMCE) running in Firefox. That makes this a bug.

My suggestion would be that whatever code you are executing as part of the ConvertToXhtml filter that prevents *YOUR* editor from inserting a <br> needs to execute unconditionally to prevent the <br> - whether or not the ConvertToXhtml filter is enabled or not.

[Ianko]

Hello Trevor,

I researched the TinyMCE editor on my end, and what I found out is that it always adds a P tag inside the content area. By that, the BR will never appear. This is a possible option to prevent the appearance of the BR, but it is quite a drastic approach. To add HTML content into the editable area without the knowledge of the user/editor is considered as an incorrect behavior in the RadEditor. Due to that, such an approach will never be implemented.

The BR appearance, as already mentioned, is handled via the filter. By means of using HTML elements to provide an editable area, I do not see what other approach is available to remove the BR. And by means of disabling the ConvertToXhtml filter (which is never a recommended option), the logic to handle the BR is disabled.

I can only make guesses why would you need to disable this filter. I assume it is due to some custom HTML content requirements. If this is so, you should note that using the RadEditor in a custom scenario, all side effects from interacting with the built-in tools, filters, logic etc. should be handled per case by the developer of the application. For example, in this case, you can always implement a custom filter to strip down this <br>, and this demo (Custom Content Filters) illustrates how to do that.

Regards,
Ianko
Telerik

 

 

[Trevor]

Hi Ianko,

First of all, this is not a custom implementation. Our customer disabled the ConvertToXhtml filter, which is a supported action by the RadEditor. If you don't want to support the editor with this filter disabled, you should not allow it to be disabled.


You said: "To add HTML content into the editable area without the knowledge of the user/editor is considered as an incorrect behavior in the RadEditor."

This is precisely the bug I am reporting to you. Clearly, this is exactly what the RadEditor is doing as I demonstrated in the linked video in my original post.

The RadEditor is adding html content (on Firefox only) into the editable area without the knowledge of the user. And I agree it is incorrect behavior and I am asking you to fix it.

One solution as I suggested is to ensure the code that currently runs within the ConvertToXhtml filter to prevent the insertion of the <br> is run UNCONDITIONALLY whether the filter is enabled or not. Why would such a behavior be limited to the ConvertToXhtml filter in the first place?

[Stanimir]

Hello,

Actually there is a such filter implemented in our code (it is called MozillaRemoveLastBrFilter) and it is added to the editor's filter manager only if ConvertToXhtml filter is enabled. Indeed it is questionable if this filter can be considered as a part of the ConvertToXhtml functionality, how ever merging it to it is a result from a multiple client requests in the past. I will log the issue for a discussion again, but it is not necessary that this behavior will change.

The easiest way to work around the problem is to add the filter right back in a ClientLoad event handler of the control. You can use the next sample as reference:

<telerik:RadEditor ID="RadEditor1" runat="server" ContentFilters="IECleanAnchors" OnClientLoad="onClientLoad"></telerik:RadEditor>
<script type="text/javascript">
    function onClientLoad(editor, args) {
        var editorFiltersManager = editor.get_filtersManager();
        editorFiltersManager.add(new Telerik.Web.UI.Editor.MozillaRemoveLastBrFilter());
    }
</script>

Regards,
Stanimir
Telerik