tracker issue : CF-3600667

select a category, or use search below
(searches all categories and all time range)

Stupid (but trivial) bug with htmlEditFormat()

| View in Tracker

Status/Resolution/Reason: Closed/Withdrawn/

Reporter/Name(from Bugbase): Adam Cameron / Adam Cameron (Adam Cameron)

Created: 07/24/2013

Components: Language

Versions: 9.0.1

Failure Type: Data Corruption

Found In Build/Fixed In Build: 9.0.1 /

Priority/Frequency: Critical / Some users will encounter

Locale/System: English / Win XP All

Vote Count: 0


Basically htmlEditFormat() replaces CRLF with LF.

This is low-impact, but it should be sticking within remit, and not messing with stuff it shouldn't be.

Should probably check other similar functions to make sure they don't do the same.

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3600667

External Customer Info:
External Company:  
External Customer Name: Adam Cameron.
External Customer Email:  
External Test Config: My Hardware and Environment details:



Closing bug as "AsDesigned". HTMLEditFormat does not preserve "Return Characters" as mentioned in the docs,
Comment by Immanuel N.
14825 | January 08, 2014 12:12:41 AM GMT
For goodness sake. I'm not suggesting there's a bug in the implementation, I'm suggesting there's a bug in the *design*. I know it's documented to remove "return" characters, but it *shouldn't* be doing that. It should not have been designed that way. The remit of the function is "Replaces special characters in a string with their HTML-escaped equivalents.". CHR(13) is NOT a "special character", so does not fall within the remit of what the function is supposed to be doing. And even if it did, the remit of the function is "Replaces [...] with their HTML-escaped equivalents". Not *remove* them. So even if for some reason you decided addressing CHR(13) characters was valid, then what you ought to be doing is REPLACING them with &#0D; Not *removing them*. What you're saying is akin to if Adobe released a function pi() which returned "4", and was designed and documented as returning "4". That doesn't make it correct, it just makes the design wrong. -- Adam
Comment by External U.
14826 | January 08, 2014 03:46:51 AM GMT