TinyMCE - Forum / TinyMCE / Tips, Tricks & HowTo's / mceNonEditable and Backspace (2023)

EDIT: Lol, after posting this I go and use the 'del' key and realized that the content is pulled out of the previous tag as its deleted, in turn leaving the 'mceNonEditable' tag empty. The fix below will work for backspace, not the del key.

I'm running Windows XP, and have experienced this issue within Firefox and IE. Using editor Version 3.0.8

When an element with the class "mceNonEditable" is added to the editor, it disallows any content modification to happen within that tag.

Now, by placing your cursor within content before or after that 'mceNonEditable' tag, you can press the 'Del' key or 'Backspace' key, and if you hold it down it will simply ignore the non-editable content block.

I believe it is an issue within the 'onNodeChange' script, cause the onNodeChange only seems to actually call when the backspace key, or del key is un-pressed (or onKeyUp).

Instead of going through a second registration (sourceforge for the bug reports), I decided to simply create a work around on the issue, so instead of messing with the main code, I figured a plugin was the way to go. The best way was to modify the 'noneditable' plugin.

I'm kinda new to the editor, but for the most part its all real simple, (congrats on that!) my only issue is I'm not to sure how to go about 'updating' this module for everyone else to use, so figured I'll just post the fix here, and maybe one of the developers can go ahead and add this in or fix the issue.

If you add the following snippet of code to that plugin above the nodechange it will cause the script to stop once inside the 'mceNonEditable' tag like it should.

ed.onKeyDown.add(function(ed, e) {
var dsc, dec;

if(e.keyCode == 8 || e.keyCode == 46) {
dsc = ed.dom.getParent(ed.selection.getStart(), function(n) {
return ed.dom.hasClass(n, nonEditClass);
});

dec = ed.dom.getParent(ed.selection.getEnd(), function(n) {
return ed.dom.hasClass(n, nonEditClass);
});

if (dsc || dec) {
return Event.cancel(e);
}
}
});

Last edited by Casey (2008-06-21 06:17:40)

Hi Casey,

in my opinion the idea of a nonEditable area will never work reliably because if you have a selection that extends over a nonEditable part and then delete the selected content (no matter with which functionality, be it cut, delete or paste) then your nonEditable area will be gone! Entirely. And there's nothing anybody can do about this.

This is why I think you should have at least two editors in this case. One editor for the part before a nonEditable area and the other after it. This way you can then merge the contents of the editors with your nonEditable content in between.

Greetings from Germany,

Felix Riesterer.

Hey Felix,

As I said I am new to the editor, so I didn't even really think about the selection on Editable content before and after, with the nonEditableCotnent in the middle being able to be deleted. Though I have tried it and you are correct, but your solution to this I feel is a waste. I think that you can use those 'mceNonEditable' fields within the one editor to your advantage, I may do this in the future if I see it being needed in the software I am developing, but I think all that would need to be done is have the plugin grab all innerHTML within all mceNonEditable tags, and the tag name, within your current selection... arrange them within an array, your key being your tag, and your value being your innerHTML content. Since the functionality to find your start and end selection is there, simply create the array before allowing the deletion of the content selected, then cycle your array and re-create those nonEditable fields starting at the cursors current point, or the 'start' of your selection.

When it comes to the 'del' key, I think their would actually be alot more needed. You would literally have to check the next character in line before allowing the 'del' key event to return, if in the event the next character in line is a tag, simply find out if its a nonEditable tag or not, if so cancel the event....

Hi Casey,

don't forget that there are not only keys to interoperate with the editor's content... there is also a context menue and the "edit" menu of your browser. You simply can't catch every possible event which is capable of removing your selected contents!

Greetings from Germany,

Felix Riesterer.

Hey Fexil,

Your correct, their would be alot more then the simple code that is currently used on that plugin, maybe even modifying the context menu plugin to interact with the nonEditableContent aswell, or any other plugins for that matter that could possibly modify that non-editable content. Though this may be a factor, I think the possability to do all of this IS there, right down to the browser interaction with the 'Edit' menu. Using an API google has released called 'Gears++', which is fully open source, I am sure you can interact with those functions, it is just a matter of someone building the plugin, and interaction with Gears to do it.

Don't get me wrong, I am not about to do it as I don't need the extensiveness of that, as my script modifies anything within the non-Editable-Content fields on submit anyway, and for the fact that the majority of my users wont even realize the possibility of the browser 'Edit' and 'Delete' functions. So if they end up removing or modifying content within those tags, big deal...

As soon as I have completed this project I am working on, and start making money on it (hah, IF, right?) I plan on send some your guys' way, as well as buying the full commercial license, as I feel you guys have created a awesome script, and really easy to work with, and build on to. If you guys ever need help working on bug fixes or addons, and dont mind the help, I know html, php, 'mysql' as my db knowledge, js, and the whole 'ajax' interactions, and 'web 2.0' standards... Gears is my next step, interaction with desktop and browser shit IS the future of development, heh..

Feel free to fix any issues you might find and send in a patch to the SourceForge patches section. We haven't placed that much time on the noneditable plugin and we will probably not do so since there have so far not been a single bug report on that plugin so I guess no one is using it anyway.

Best regards,
Spocke - Main developer of TinyMCE

Hey Spocke,

Bleh sourceforge, lol, I'd rather sit in the background and email ya'll bug fixes. If I've come to the understanding, your the one that developed this, its a great software, congrats!

I figure you guys have more important issues to deal with then the nonEditable content, to be honest with you the only reason I am using it is so I didn't have to build my own, you had all already thought of it. I'm simply using it as a 'place holder' of implemented content, once my form is submitted a couple preg_replace's deal with the removal of the noneditable boxes and places a tag in its place for my scripts to work with later. I figured if I fixed something, regardless of how many people use the function, I might as well let your little community here know about it. You never know, maybe someone will need the function as much as I did, it doesn't hurt to build onto already started functions, atleast in my opinion

Your editor cleared about half my projects todo list, in return I feel that when my company launches you deserve some sort of return, I mean we all need boos, right? lol. On top of it all, I figure if your editor is the one I plan on using for the rest of the project, and I do, I might as well help to improve it where ever assistance is needed, if any, ofcourse.

Any complete fixes for this yet? I have the same problem with DEL and Backspace keys?
Any help would be appreciated.

Spocke, with all respect for your work...I guess you are wrong There are and there will be a lot of peoples having this problem but from the end user point of view, not from the coder and end-users will never report this.

So please, try and find a fix for this. Thanks.

Last edited by sergiu_em (2010-01-06 16:44:30)