All users were logged out of Bugzilla on October 13th, 2018
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, 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
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, 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.