BR AND P tags not handled correct in IE6 and IE7

[bongobongo]

Hi.

Using FCKeditor 2.4.3 and had high expectations for the new handling of BR and P tags (introduced earlier).

I do not want P tags in the source, and have therefore these two lines in my fckconfig.js: FCKConfig.EnterMode = 'br' ; FCKConfig.ShiftEnterMode = 'br' ;

And have the following UGLY (at least for me) bug:

If I enter some text and then use BACKSPACE TO REMOVE ALL text (in IE6 or IE7) then what is stored in my database is this: <p>&#160;</p>

There should be nothing stored in my db.

Then when I laiter edit the text in FCKeditor then the P tags are never gone.

Is this a known bug? Is there something else I have to set in the config file to handle this correct?

REALLY hopy this can be fixed ASAP, also for the 2.4.3 version, since I'm soon to demo an application for a customer and would not like to use a 2.5 beta or a clean 2.5 version since this increase the risk of new quirks in the application.

It works as it should in Firefox.

[Alfonso Martínez de Lizarrondo]

You must test the bugs using the latest version (better if you test also the nightly), there's no chance to release a 2.4.x version with just one bug fix unless it's a very serious problem, and this isn't.

[bongobongo]

I'm surprised that you say it is not a serious problem.

As far as I know it, 2.5 is just a beta. I'm a developer and would NEVER use a beta FCKedtior in my projects. I highly doubt many other would do that as well.

Also I do not have time to test a beta version. I have enough with testing and reporting stuff for the 2.4.3 version.

Therefore I consider testing this bug in a beta version, is not my job and should not be of my consern. It should be a job for the core FCKeditor developers.

And I DO consider this a SERIOUS bug. Reason is this. FCK developer state that all browsers should handle BR and P tags the same.

My report here shows that that is not the case. This also affects all other developers and their customers using FCKeditor and using this setting in fckeditor.js: FCKConfig.EnterMode = 'br'; FCKConfig.ShiftEnterMode = 'br';

The risk that some of my customers do exactly what I did to get the bug is there and that is not a good thing for me. I do not allow P tags, ref the way I use fckgonfig.js and would expect P tags not to be inserted by the browser.

I really really hope that you could reconsider your statement that this is not a serious bug. If not, then at least I think you should focus on getting a bugfree 2.4.3 out to the developers (us) instead of pushing new versions with potentially new bugs out.

[Alfonso Martínez de Lizarrondo]

Replying to bongobongo:

I'm surprised that you say it is not a serious problem.

Surely not enough to force a release of 2.4.x having the 2.5 almost ready.
I wonder what will happen as you or your users come accross any of the bug fixed for the new version, and they are quite a lot: ​http://www.fckeditor.net/whatsnew (many/almost all much more important than this one)

As far as I know it, 2.5 is just a beta. I'm a developer and would NEVER use a beta FCKedtior in my projects. I highly doubt many other would do that as well.

You don't have to use the beta in a production enviroment, but if you don't test it then you can't come back here when 2.5 is released and then say that this and that is broken and should have been fixed before release. Betas in any product are there so people can test them before the final release and find any new bugs that might have slipped.

Also I do not have time to test a beta version. I have enough with testing and reporting stuff for the 2.4.3 version.

version 2.4.3 was released almost five months ago, if you're the only one that have found this problem, and only now, then it probably isn't such a big deal.
And if you just can't take 5 minutes to test the problem in a nightly version, then I wonder why do you expect anyone else to take the time to look at it for you.

And I DO consider this a SERIOUS bug.

I say that this is trivial. You can workaround it very easily.

If not, then at least I think you should focus on getting a bugfree 2.4.3 out to the developers (us) instead of pushing new versions with potentially new bugs out.

Did you take a look at the number of bug that have been fixed for 2.5?
And the number of bugs that are still in this tracker?
Having a bugfree version would mean not releasing any new version for several years. (and in order to fix many bugs some new features are required)

[Wojciech Olchawa]

Hi!

Could you please check if the bug still occurs in the newest version 2.5.1. I've tried to reproduce it both on IE6 and IE7 and I had normal (expected) results.

Thanks.

[bongobongo]

Have just tested it in IE6/7 and could not reproduce.

Best

[Wojciech Olchawa]

Replying to bongobongo:

Have just tested it in IE6/7 and could not reproduce.

Best

Ok , so becasue the bug no longer occurs I'm closing this ticket. Thanks for you investigation.

Best regards.