#1905: POSTed data sometimes HTML encoded sometimes not
---------------------------------+------------------------------------------
Reporter: Kyle | Owner:
Type: Bug | Status: reopened
Priority: Normal | Milestone:
Component: Core : Output Data | Version: SVN
Resolution: | Keywords: Confirmed
---------------------------------+------------------------------------------
Changes (by Kyle):
* status: closed => reopened
* resolution: invalid =>
Comment:
Replying to [comment:2 fredck]:
> Replying to [ticket:1905 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> &".
>
> 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 < & >
" some..."? Either A or B below will happen.
A. They're in Source mode when they typed it in and submit the form. My
POST processing page will get "This is < & > " 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.
B. They're in WYSIWIG mode when they submit. 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 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?
--
Ticket URL: <http://dev.fckeditor.net/ticket/1905#comment:3>
FCKeditor <http://www.fckeditor.net>
The text editor for Internet
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
FCKeditor-Trac mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fckeditor-trac
