POSTed data sometimes HTML encoded sometimes not

[Kyle]

While in Source mode the characters are not encoded as HTML entities for POST. While in normal mode (the usual mode for editing with FCKeditor) the characters are HTML encoded for POST. Whether the POST data is HTML encoded or not depends entirely on what mode the user had FCKeditor in when they submit the form which makes it impossible to do the correct thing when gathering the POSTed data.

Clicking back and forth between Source and Normal mode encodes the text as HTML entities, although it does not keep re-encoding them over and over again on each switch between Source and normal mode.

Here's how to reproduce the problem:

1. Choose any of the PHP samples on the nightly samples page. It works the same (badly) on all of them.

2. Without changing any of the styles, enter the text '< & > "' between 'is' and 'some', so the plain text would read This is < & > " some sample text.

3. Submit the form. You get a new browser window with the data as "This is &lt; &amp; &gt; &quot; some..." This is the problem. All of the samples have HtmlEncodeOutput set to the default value of 'false' so that all of those characters should NOT be encoded as html entities. Plain old <textarea> form fields do no encode those characters for the POST.

4. Now go back to the form, and click on the "Source" button in the FCKEditor toolbar. You'll see that the text indeed shows "This is &lt; &amp; &gt; &quot; some...".

5. While in Source mode view, remove those encoded symbols and put in the original symbols of '< & > "'. Leave the FCKEditor in Source mode and Submit the form. The new browser window now shows the data being posted as 'This is < & > " some..." which is what it should always be.

Browser: Tested on FireFox 2.0.12 and Safari 3.0.4 on Mac OS X 10.5.2.

[Wojciech Olchawa]

Confirmed in FF2, Safari and IE.

[Frederico Caldeira Knabben]

Replying to Kyle:

'This is < & > " some..." which is what it should always be.

This assumption on totally wrong. It is definitely correct to encode those chars. Just to exemplify, in WYSIWYG mode instead of typing "< & >", type "<b> &amp;".

While in source view, things are completely different. Actually, the editor don't touch the source in that case as it expects the user to know what s/he is doing there. It just posts the data as is. This is a feature.

HtmlEncodeOutput has nothing to do with it. It is a feature that encode the data when posting, so the POST data will contain plain HTML tags.

[Kyle]

Replying to fredck:

Replying to Kyle:

'This is < & > " some..." which is what it should always be.

This assumption on totally wrong. It is definitely correct to encode those chars. Just to exemplify, in WYSIWYG mode instead of typing "< & >", type "<b> &amp;".

While in source view, things are completely different. Actually, the editor don't touch the source in that case as it expects the user to know what s/he is doing there. It just posts the data as is. This is a feature.

HtmlEncodeOutput has nothing to do with it. It is a feature that encode the data when posting, so the POST data will contain plain HTML tags.

So what you're telling me is that I have no control (and you don't consider it a bug) that sometimes my form submission processing page will get POSTed data that's HTML encoded and sometimes it wont. Which I get depends on the user being in either Source mode or WYSIWIG mode, which I have no control over AND no way to tell from the POSTed data.

The user means exactly the same thing in both cases. Is the processing page supposed to always decode HTML entities from the posted data? Is the processing page supposed to NOT always decode HTML entities from the posted data? It has to be one or the other.

What if the user is trying to type in literally "This is &lt; &amp; &gt; &quot; some..."? Either A or B below will happen.

1. They're in Source mode when they typed it in and submit the form. My POST processing page will get "This is &lt; &amp; &gt; &quot; some...". If I run it through an entity decoder, I'll have "This is < & > " some..." which is NOT what the user wants. If I don't use the entity decoder, I get what the user wanted.

2. They're in WYSIWIG mode when they submit. My POST processing page will get "This is &amp;lt; &amp;amp; &amp;gt; &amp;quot; some...". If I run it through an entity decoder, I'll have "This is &lt; &amp; &gt; &quot; some..." which is exactly what the user wants. If I don't use the entity decoder, I'll get something double-encoded which is NOT what the user wants.

Do you see the problem now?

How can you possibly say that's not a bug?

[Kyle]

Replying to fredck:

Replying to Kyle:

'This is < & > " some..." which is what it should always be.

This assumption on totally wrong. It is definitely correct to encode those chars.

It is NOT at all correct to encode those characters. Here's a different take on it if you don't buy the Source vs WYSIWIG argument.

1. Use a standard <textarea> in a form. If you type in 'This < & > " some...' in the textarea and submit the form, then the POSTed data will be 'This < & > " some...' No surprises. It's exactly what the user typed.

2. Use a standard FCKeditor in a form. Leave it in WYSIWIG mode. If you type in 'This < & > " some...' in the FCKeditor and submit the form, the POSTed data will be 'This &lt; &amp; &gt; &quot; some...' This is a huge surprise and is NOT what you typed in.

If FCKeditor is supposed to be a drop-in replacement for <textarea> elements, then it should not encode characters as HTML entities that the user types in.

[Wojciech Olchawa]

Which I get depends on the user being in either Source mode or WYSIWIG mode, which I have no control over AND no way to tell from the POSTed data.

Hi!

You can have control about the mode that the user is in. You can just simply remove the source view button from the toolbar and erase the keystroke to Source View and than you will be certain that someone will only use the WYSIWYG view in spite of the Source View.

The second thing is that when someone is using the Source View the assumption is that h/she is an advanced user and knows the basics of HTML. Otherwise why should the user be allowed to write in the Source View.

[Frederico Caldeira Knabben]

Kyle, I'm sure you are aware about the HTML specifications, so you should instruct your users so they will understand how things work. If they are unable to understand that &lt; is the HTML way to render < in the screen, then it is better to not give them access to the Source view.

Also, a textarea is used to output "plain text". FCKeditor is used to output HTML.

The simple example if typing "<b>" in both cases explain the difference. With a textarea system you may save that value as plain "<b>", taking case of HTML enconding it when injecting it in a page, so you transform it in HTML: "&lt;b&gt;".

FCKeditor instead already outputs HTML. So, if you type "<b>" in the WYSIWYG view, you save it as "&lt;b&gt;" automatically, so you don't need to HTML encode it to inject it in a page.

[Wojciech Olchawa]

#1516 has been marked as DUP