Opened 16 years ago
Closed 16 years ago
#2932 closed Bug (fixed)
AJAX sample fails to populate editing area after subsequent editor instantiations in FF 3
Reported by: | Damian | Owned by: | Frederico Caldeira Knabben |
---|---|---|---|
Priority: | Normal | Milestone: | CKEditor 3.0 |
Component: | General | Version: | 3.0 Beta |
Keywords: | Confirmed IBM HasPatch Review+ | Cc: |
Description
Instances of the editor which have been dynamically created using CKEDITOR.appendTo() fail to properly handle insertHTML(). The first instance of the editor works as expected but when that instance is destroyed and another created in its place, the second instance and all subsequent instances will fail to handle insertHTML().
The behavior can be reproduced by following these steps:
- Open http://ckeditor.com/ckeditor/3.0b/_samples/ajax.html
- Create editor
- Enter content into editing area
- Destroy editor
- Create another editor
Expected behavior is that the entered content would be populated in the new editor instance, but it isn't.
The cause has been tracked down to the mode of the editor not being set before setHTML() is called.
A temporary fix for the problem is to update CKEDITOR.editor.prototype.setMode declared in the editingblock plugin and explicitly set the mode (see patch).
The erroneous behavior appears to occur only in Firefox 3.
Attachments (2)
Change History (7)
Changed 16 years ago by
Attachment: | 2932.patch added |
---|
comment:1 Changed 16 years ago by
Keywords: | Confirmed IBM HasPatch added |
---|---|
Summary: | AJAX sample fails to populate editing area after subsequent editor instantiations in FF 3 [IBM] → AJAX sample fails to populate editing area after subsequent editor instantiations in FF 3 |
Changed 16 years ago by
Attachment: | 2932_2.patch added |
---|
comment:2 Changed 16 years ago by
Keywords: | Review? added |
---|---|
Owner: | set to Frederico Caldeira Knabben |
Status: | new → assigned |
comment:3 Changed 16 years ago by
Keywords: | Review+ added; Review? removed |
---|
comment:5 Changed 16 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
We have originally implemented the "mode" property set in the way you have proposed. But, the WYSIWYG mode takes time to get rendered and other parts of the code depends on it to be ready to perform some actions. For that, we had to make the "mode" being set asynchronously.
This new patch considers this "asynchronousity" aspect, ensuring that the data get loaded as soon as the mode is ready.
The patch also fixes an issue in the event system, which came to the light when fixing this ticket.