Opened 15 years ago
Closed 15 years ago
#4241 closed Bug (fixed)
Styles menu gets "stuck" on editor.destroy()
| Reported by: | Steve Smale | Owned by: | Garry Yao |
|---|---|---|---|
| Priority: | Normal | Milestone: | CKEditor 3.1 |
| Component: | UI : Floating Panel | Version: | 3.0 RC |
| Keywords: | Confirmed HasTest Review+ | Cc: |
Description
I have many times experienced this bug which can be caused when an event (such as clicking in another area (which in my app does an editor.destroy() then a new editor.replace) when the "Styles" dropdown menu is open.
This leaves the "styles" menu on screen, when CKEditor itself has been unloaded. Clicking on the styles in the menu doesnt make it go away, and if loading a new editor instance it is impossible to open the styles menu again.
I have attached a screenshot showing the "stuck" styles menu, and also a list of the errors shown in Safari's console.
This happens with the latest nightly, 3.0 build 4098.
Attachments (5)
Change History (14)
Changed 15 years ago by
| Attachment: | console.jpg added |
|---|
Changed 15 years ago by
Stuck styles popup after the editor has been .destroy()d
comment:1 Changed 15 years ago by
I wonder if it is possible to double check and ensure all dropdown menus are safely CLOSED and REMOVED when editor.destroy() is called....
comment:2 Changed 15 years ago by
Here is some stripped-down example code which demonstrates this issue.
To reproduce the bug:
Put this HTML file in the same folder as ckeditor.js and open in a browser
- Click on "Area One"
- Click to open the "Styles" menu
- Click on "Area Two"
Example.html follows:
<html>
<script type="text/javascript" src="ckeditor.js"></script>
<div onClick="replaceDiv('area1');" id="area1" style="float:left; padding:10px; border:1px solid; width:400px; height:400px;">Area One</div>
<div onClick="replaceDiv('area2');" id="area2" style="float:left; padding:10px; border:1px solid; width:400px; height:400px;">Area Two</div>
<script type="text/javascript">
var editor=null;
CKEDITOR.config.toolbar_Full = [['Styles','Bold','Italic','Underline']];
function replaceDiv(div)
{
if ( editor )
{
removeEditor();
}
editor = CKEDITOR.appendTo( div,{});
}
function removeEditor()
{
if ( !editor )
return;
editor.destroy();
editor = null;
}
</script>
</html>
Changed 15 years ago by
| Attachment: | example.html added |
|---|
Changed 15 years ago by
| Attachment: | example.result.jpg added |
|---|
comment:3 Changed 15 years ago by
| Keywords: | Confirmed added |
|---|---|
| Milestone: | CKEditor 3.0 → CKEditor 3.1 |
| Priority: | High → Normal |
Ticket test added with [4102] at : source:CKEditor/trunk/_test/tt/4241/4241.html
comment:4 Changed 15 years ago by
Have found a workaround for this. Setting focus back to the editor immediately prior to destroying it ensures that the popup menu loses focus and cleans up.
Thus, replacing:
editor.destroy();
with:
editor.focus(); editor.destroy();
will make the "removeEditor()" function in my example 'safe' from this bug.
This might help anyone else encountering this bug in CKE 3.0, as I notice that resolution of this bug has been deferred to release 3.1
(Or maybe a focus() is a quick fix that could be included in 3.0's destroy() function to avoid releasing with this bug?)
comment:5 Changed 15 years ago by
| Owner: | set to Garry Yao |
|---|---|
| Status: | new → assigned |
@sesmale: Thanks for the tips, the above workaround has the following problems:
- Doesn't work for an opened dialog;
- Break user focus if on other elements of the host page;
- Still leaving editor nodes at end of body.
I'm proposing another fix for it.
Changed 15 years ago by
| Attachment: | 4241.patch added |
|---|
comment:6 Changed 15 years ago by
| Keywords: | Review? added |
|---|
comment:7 Changed 15 years ago by
| Keywords: | HasTest added |
|---|
comment:8 Changed 15 years ago by
| Keywords: | Review+ added; Review? removed |
|---|
comment:9 Changed 15 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Safari's error console