Opened 7 years ago
Closed 7 years ago
#4241 closed Bug (fixed)
Styles menu gets "stuck" on editor.destroy()
| Reported by: | sesmale | 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 7 years ago by sesmale
comment:1 in reply to: ↑ description Changed 7 years ago by sesmale
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 7 years ago by sesmale
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 7 years ago by sesmale
Changed 7 years ago by sesmale
comment:3 Changed 7 years ago by garry.yao
- Keywords Confirmed added
- Milestone changed from CKEditor 3.0 to CKEditor 3.1
- Priority changed from High to Normal
Ticket test added with [4102] at : source:CKEditor/trunk/_test/tt/4241/4241.html
comment:4 Changed 7 years ago by sesmale
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 7 years ago by garry.yao
- Owner set to garry.yao
- Status changed from new to 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 7 years ago by garry.yao
comment:6 Changed 7 years ago by garry.yao
- Keywords Review? added
comment:7 Changed 7 years ago by garry.yao
- Keywords HasTest added
comment:8 Changed 7 years ago by tobiasz.cudnik
- Keywords Review+ added; Review? removed
comment:9 Changed 7 years ago by garry.yao
- Resolution set to fixed
- Status changed from assigned to closed
Safari's error console