All users were logged out of Bugzilla on October 13th, 2018

AJAX ASP.NET special characters displayed/saved incorrectly

RESOLVED INCOMPLETE

Status

()

RESOLVED INCOMPLETE
10 years ago
8 years ago

People

(Reporter: sopht, Unassigned)

Tracking

3.5 Branch
x86
Windows Vista
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [CLOSEME 2011-2-25])

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; InfoPath.2; .NET CLR 3.5.21022; .NET CLR 3.0.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3

using Telerik's RadEditor for AJAX ASP.NET
http://www.telerik.com/products/aspnet-ajax/editor.aspx
the form will incorrectly save and incorrectly redisplay any special (non alphabetical or numerical) characters causing incorrect displaying of the saved document.

For example:

<br> is saved and redisplayed as ~3cbr~3e, &nbsp; is displayed as ~26nbsp~3b and ! is displayed as ~21

essentially breaking any HTML saved in the form.  This is true of both the wysiwyg and code versions of the program.

This form worked perfectly in firefox 3.0.7 on the same system

Reproducible: Always

Steps to Reproduce:
1. open an article with radeditor
2. save the article with any type of html in it
3. view the saved article
Actual Results:  
all html is broken causing the page to display all code in ASP/AJAX 'safe' code mode (added slashes) as stated above.  breaking all html/css images and formatting.

Expected Results:  
html characters should be saved and displayed correctly and a validated code snipped should appear correctly

this was tested on the same system immediately before and after upgrading to firefox 3.1b3 from 3.0.7
(Reporter)

Comment 1

10 years ago
navigate to:

http://demos.telerik.com/aspnet-ajax/editor/examples/default/defaultcs.aspx

and on the right-hand toolbar where it says "Enable/Disable RadEditor:"

toggle from 'enabled' to 'disabled' to see the bug in action.  Toggle again from 'disabled' to 'enabled' to see it again - the text should return to its original formatting
(Reporter)

Updated

10 years ago
Version: unspecified → 3.1 Branch
Reporter, are you still seeing this issue with Firefox 3.6.13 or later in safe mode or a fresh profile? If not, please close. These links can help you in your testing.
http://support.mozilla.com/kb/Safe+Mode
http://support.mozilla.com/kb/Managing+profiles
Whiteboard: [CLOSEME 2011-2-25]
This bug has had the CLOSEME tag for several weeks and the date in the tag is
far gone. If the reporter can still see this issue, Please retest with Firefox
3.6.x or later and a new profile
(http://support.mozilla.com/kb/Managing+profiles). Then please remove the
closeme tag in the whiteboard, mark the bug against the proper version and
comment on the bug.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.