if an editor is read only, then the backspace key is blocked by this code:
keystrokeHandler.blockedKeystrokes[ 8 ] = editor.readOnly;
However if I change a readOnly mode by calling the setReadOnly(false)
function later, the backspace key is still blocked.
Maybe it is a good idea to active the backspace key if setReadOnly(false)
is called.
--
Ticket URL: <http://dev.ckeditor.com/ticket/9761>
CKEditor <http://ckeditor.com/>
The text editor for the Internet
* status: new => pending
Comment:
I have just checked readOnly sample in latest editor 4.0 and didn't get
this problem - backspace is working as expected.
In which browsers were you getting this problem, what are steps to
reproduce this, what is the code that is causing this and can this problem
be reproduced in latest editor 4.0?
--
Ticket URL: <http://dev.ckeditor.com/ticket/9761#comment:1>
Comment (by limuhob):
Replying to [comment:1 j.swiderski]:
> I have just checked readOnly sample in latest editor 4.0 and didn't get
this problem - backspace is working as expected.
>
> In which browsers were you getting this problem, what are steps to
reproduce this, what is the code that is causing this and can this problem
be reproduced in latest editor 4.0?
Problem is in google chrome 23 on linux. Same problem in the latest editor
4.0. Sample code is here. Sorry for jquery:
{{{
<head>
<script>
$(document).ready(function(){
var $editme = $("#editor1");
var editor = CKEDITOR.inline($editme.get(0));
//hide contenteditable and make editor readOnly
$editme.hide();
$("#activate").bind("click", function(e){
//show contenteditable and make editor writable
$editme.show();
editor.setReadOnly(false);
//now backspace doesn't work
});
});
</script>
</head>
<body>
<input id="activate" type="button" value="activate editable"/>
<div id="editor1" contenteditable="true">
sample
</div>
</body>
}}}
--
Ticket URL: <http://dev.ckeditor.com/ticket/9761#comment:2>
Comment (by jmiserez):
I can confirm this bug on Windows 7 with Chrome 23.0.1271.95m. It does not
occur on IE9 or Firefox.
Specifically, I have this issue with a (huge) dynamic web application with
multiple inline CKEditor instances, one of which is created in a DOM tree
which is not attached to the document. When this tree is then attached to
the document, the setReadOnly(false) indeed does not change the backspace
handling back to normal.
So in my code, I was able to fix this issue using the following code
(_editor is my CKEDITOR.editor instance)
{{{
setReadOnly: function(readOnly) {
if (this._editor.readOnly !== readOnly) {
this._editor.setReadOnly(readOnly);
if (!readOnly) {
delete this._editor.keystrokeHandler.blockedKeystrokes["8"];
//8 is Backspace
}
}
}
}}}
I will try to investigate this further, as it is impossible for me to give
you a short testcase.
--
Ticket URL: <http://dev.ckeditor.com/ticket/9761#comment:3>
* cc: jeremie@… (added)
* version: 4.0 Beta => 4.0
* type: New Feature => Bug
--
Ticket URL: <http://dev.ckeditor.com/ticket/9761#comment:4>
* cc: jan_wloka@… (added)
Comment:
Subscribed.
--
Ticket URL: <http://dev.ckeditor.com/ticket/9761#comment:5>
* cc: jan_wloka@… (removed)
* status: pending => closed
* resolution: => invalid
Comment:
I have tried to reproduce this issue but with on luck.
@limuhob one thing I have noticed - beside code being incomplete is that
you should rather set editor to readOnly on instanceReady event. That way
it has always worked for me without problems.
{{{
var $editme = $("#editable");
$editme.attr('contenteditable', true);
CKEDITOR.disableAutoInline = true;
var editor = CKEDITOR.inline($editme.get(0));
//hide contenteditable and make editor readOnly
editor.on('instanceReady', function(ev){
editor.setReadOnly(true);
$editme.hide();
});
$("#activate").bind("click", function(e){
//show contenteditable and make editor writable
$editme.show();
editor.setReadOnly(false);
//now backspace doesn't work
});
}}}
I'm closing this issue as invalid. If you guys are able to provide
working and reduced sample file that shows this problem please do so and I
will reopen this issue.
--
Ticket URL: <http://dev.ckeditor.com/ticket/9761#comment:6>
Comment (by dynamicplus):
I can confirm this bug on chrome/safari.
This bug is related to "auto readonly" feature on contenteditable/inline.
To reproduce simply...
Create a page with jqueryUI tabs.
Place an inline editor on each page (div).
Then call CKEDITOR.inline();
Now initialize tabs().
If you switch to second tab (the hidden one) the editor will be readOnly,
so i have a change-tab callback...
activate: function( event, ui )
{
if ( _.aFeaturedDialogWysiwygEditors )
{
for ( var i in _.aFeaturedDialogWysiwygEditors )
{
try
{
// this is the result of CKEDITOR.inline
_.aFeaturedDialogWysiwygEditors[i].setReadOnly(
false );
if (
_.aFeaturedDialogWysiwygEditors[i].keystrokeHandler &&
_.aFeaturedDialogWysiwygEditors[i].keystrokeHandler.blockedKeystrokes &&
'8' in
_.aFeaturedDialogWysiwygEditors[i].keystrokeHandler.blockedKeystrokes )
delete
_.aFeaturedDialogWysiwygEditors[i].keystrokeHandler.blockedKeystrokes['8'];
}
catch ( e )
{
}
}
}
//...
}
--
Ticket URL: <http://dev.ckeditor.com/ticket/9761#comment:7>
Comment (by j.swiderski):
@dynamicplus instead of me creating files and guessing what you had in
mind could you please create sample test page that show the problem (HTML
page that can be put in samples folder and will show the bug (jquery can
be imported from Google code) ).
That way we will be working on the same code.
----
There is however one problem. You have written:
>If you switch to second tab (**the hidden one**) the editor will be
readOnly
This may have something to do with -
http://dev.ckeditor.com/ticket/9835#comment:2
Please provide the sample so that I could see code you are having problems
with and base on it I will be able to tell more.
--
Ticket URL: <http://dev.ckeditor.com/ticket/9761#comment:8>
* keywords: => IBM
* cc: jan_wloka@… (added)
--
Ticket URL: <http://dev.ckeditor.com/ticket/9761#comment:9>
* cc: joel.peltonen@… (added)
Comment:
subscribed
--
Ticket URL: <http://dev.ckeditor.com/ticket/9761#comment:10>
Comment (by req):
This should not be closed. Here is a sample of of how to reproduce it very
simply.
1. Download CKE 4.1 standard
2. Extract to wherever
3. Download the attached sample THISTEST.html
4. Open in IE9, Allow it to run the script
5. Click "Unleash" button
6. Click some text
7. Press Backspace; does not work.
This is a very common error for me but I Finally just now nailed it down
what caused it.
--
Ticket URL: <http://dev.ckeditor.com/ticket/9761#comment:11>
Comment (by req):
Sorry to spam you all, but I found a workaround. In my example, the
following fails:
{{{
function derp() {
editor.setData("<p>Lorem ipsum dolor sit amet</p>", function() {
editor.setReadOnly(false);
});
}
}}}
But the following works:
{{{
function derp() {
editor.setReadOnly(false);
editor.setData("<p>Lorem ipsum dolor sit amet</p>", function() {
editor.setReadOnly(false);
});
}
}}}
Meaning that the bug is very closely related to setData and not just
setReadOnly. For now, it is safe to setReadOnly '''before''' setting
readOnly to false, if possible for you.
--
Ticket URL: <http://dev.ckeditor.com/ticket/9761#comment:12>
* status: closed => reopened
* resolution: invalid =>
--
Ticket URL: <http://dev.ckeditor.com/ticket/9761#comment:13>
* status: reopened => confirmed
* version: 4.0 => 4.0 Beta
Old description:
> Hi guys,
>
> if an editor is read only, then the backspace key is blocked by this
> code: keystrokeHandler.blockedKeystrokes[ 8 ] = editor.readOnly;
>
> However if I change a readOnly mode by calling the setReadOnly(false)
> function later, the backspace key is still blocked.
>
> Maybe it is a good idea to active the backspace key if setReadOnly(false)
> is called.
New description:
Hi guys,
if an editor is read only, then the backspace key is blocked by this code:
keystrokeHandler.blockedKeystrokes[ 8 ] = editor.readOnly;
However if I change a readOnly mode by calling the setReadOnly(false)
function later, the backspace key is still blocked.
Maybe it is a good idea to active the backspace key if setReadOnly(false)
is called.
----
**Edited:**[[BR]]
Please see comment:12 and comment:13 for explanation of this problem.
Issue can be reproduced in all browsers from CKEditor 4.0 beta.
--
--
Ticket URL: <http://dev.ckeditor.com/ticket/9761#comment:14>
Comment (by jduty):
I can confirm in FF 20.0.1 and IE 9.0.8112.16421.
Any word on this? Rather hard to get the staff to use the tool if
backspace is broken.
--
Ticket URL: <http://dev.ckeditor.com/ticket/9761#comment:15>
* milestone: => CKEditor 4.1.2
--
Ticket URL: <http://dev.ckeditor.com/ticket/9761#comment:16>
Comment (by ianllewellyn):
I've recently been looking into this issue as I've run into it in chrome
on OSX. I've isolated it to a specific case:
If I use CKEDITOR.inline() on an element with contenteditable="true" then
I can use CKEDITOR.setReadOnly(false) and backspace will work.
If however I use CKEDITOR.inline() on an element that does not have
contenteditable="true" then CKEDITOR.setReadOnly(false) will leave the
backspace key blocked in the keystrokeHandler.blockedKeystrokes hash.
I've attached bug.html which can be dropped into the ckeditor samples dir,
this replicates the two situations described above.
--
Ticket URL: <http://dev.ckeditor.com/ticket/9761#comment:17>
* owner: => a.nowodzinski
* status: confirmed => assigned
--
Ticket URL: <http://dev.ckeditor.com/ticket/9761#comment:18>
* status: assigned => review
Comment:
DEV: Created fix in [https://github.com/cksource/ckeditor-
dev/commits/t/9761 t/9761 branch].
TESTS: Added tests for BACKSPACE key behavior and mt for the ticket.
--
Ticket URL: <http://dev.ckeditor.com/ticket/9761#comment:19>
* status: review => review_passed
--
Ticket URL: <http://dev.ckeditor.com/ticket/9761#comment:20>
* status: review_passed => closed
* resolution: => fixed
Comment:
Merged into master: git:3b38fe9c4e0f6e (dev), a6c66688723eab60 (tests).
--
Ticket URL: <http://dev.ckeditor.com/ticket/9761#comment:21>