[IE] When you specify a title to a table, the first character is deleted

[estan]

Like the title suggests.

To reproduce, open the editor, click the button to add a table, fill for example the text 'hello' in the title field. click on OK, now you can see the table in the editor with on top the title in bold 'ello'

[estan]

I like to add that it only happens with IE(7) not with Firefox. You can even see the error in your demo  http://www.fckeditor.net/demo

debugging with VS2008 gives me the problem in fckeditorcode_ie.js

After the ok click at the end of that function you have the following line: oEditor.FCK.InsertElement( table ) ; When i ask the quick watch of the table object, you can see clearly that the caption is correct. So, it must be happening when the object is converted to html code.

Good luck

[w.olchawa]

Confirmed both in IE6 and IE7 using 2.6 beta and the latest SVN.

[fredck]

(Regression) This one is ok with version 2.5.1.

[fredck]

It seems it has been introduced with [1404].

[fredck]

The root of the problem was at FCKDomTools.MoveToElementEditStart. The logic there was not catching all cases.

I've completely rewritten that function in the patch, using now the DTD to identify the elements that can be editable. This solution is much straightforward.

I've also noted that the selection was not being placed in the right position on IE when creating forms or tables. I've done a small change on fckdialog.html. I would ask Martin to be sure that that change is ok, because I'm not sure why we have placed the Selection.EnsureSelection() call inside CloseDialog (which was making EnsureSelection be called two times for the Ok button).

[alfonsoml]

I would rename

var editable ;

to

var editableElement ;

There's a typo in fcklistslib.js // Elementst

and in the what's new: being properly handled when creating

[fredck]

Good to hear that no critical things have been found in the patch. The new one fixes all your considerations.

[martinkou]

The bug was already fixed by [1795], so it cannot be reproduce with the newest SVN code anyways. The changes to MoveToElementEditStart() is still an sensible improvement to its robustness, however.

Moving the EnsureSelection() to inside Cancel() should be ok, I don't remember any particular reason I placed the EnsureSelection() inside CloseDialog(), and I wasn't able to discover any new bugs caused by the change anyway.

[fredck]

Fixed with [1803]. Click here for more info about our SVN system.