Wysiwyg-editor: Edits in Code View do not fire contentChanged event and edited content is not available via html.get

Created on 25 May 2016  路  12Comments  路  Source: froala/wysiwyg-editor

Expected behavior.

Edits in Code View mode fire the contentChanged event and the edited content can be obtained using html.get even if the Content View is still open.

Actual behavior.

The event is not fired and calls to html.get do not return the current content as long as the Content View mode is open.

Result.

Changes are lost if the user makes changes in Code View and does not return to the normal editor view before saving.

Most helpful comment

Since Code Mirror isn't setup until it is toggled for the first time, here is what I ended up with for anyone in the future:

var $area = $('....');
$area.on('froalaEditor.commands.after', function (e, editor, cmd, param1, param2) {
    if (cmd == 'html') {
        if (editor.codeView.isActive()) {
            var mirror = editor.$box.find(".CodeMirror")[0].CodeMirror;
            mirror.on('change', function() {
                console.log(arguments);
            });
            // Turn off the commands so we don't keep binding it.
            $area.off('froalaEditor.commands.after');
        }
    }
});

All 12 comments

That is on purpose because triggering contentChanged while editing in code view might result in having bad formatted HTML which is not desired. When in codeView mode, you can get the HTML using codeView.get() method.

Is there any event we can subscribe on that will be fired when content is changed in Code View?

I'm not sure I understand why there couldn't be an event like contentChanged provided when the code view is toggled. Currently, if you're in the code view then the contentChanged event isn't fired until you toggle back to the WYSIWYG view. I have tabs for the WYSIWYG view and code views and I'm storing the html from the editor when contentChanged is fired. I don't see why or how I would require the user to toggle back to the WYSIWYG view in order for the content to change after they've been making edits in the code view.

How would you recommend figuring out when the user has made edits in the code view? None of the events for the editor seem to fire so any changes made in the code view are lost. It would be nice to have at least some event that could be used to know the user is editing or has edited the code view content.

@lostinpatterns The edits made in code view should be cleaned before inserting them in the text view. Doing that on every change from the code view is a slow operation and it might also result in HTML which is not properly written. For example, your users are starting to type in the code view <img sr and they leave it like this for a while. Now contentChanged is triggered and you get some bad HTML which the user hasn't intended to save.

But that doesn't answer the question. How can we programmatically know when the user changes the code in the code view?

There is no built-in feature for tracking code-view changes.

Is there a way to access the CodeMirror instance that froala setup in order to bind the event manually?

I think something like this should work:

code_mirror = $(selector).data('froala.editor').$box.find('.CodeMirror')[0].CodeMirror;

Since Code Mirror isn't setup until it is toggled for the first time, here is what I ended up with for anyone in the future:

var $area = $('....');
$area.on('froalaEditor.commands.after', function (e, editor, cmd, param1, param2) {
    if (cmd == 'html') {
        if (editor.codeView.isActive()) {
            var mirror = editor.$box.find(".CodeMirror")[0].CodeMirror;
            mirror.on('change', function() {
                console.log(arguments);
            });
            // Turn off the commands so we don't keep binding it.
            $area.off('froalaEditor.commands.after');
        }
    }
});

@stefanneculai Any chance this feature could be implemented? I also ran into a similar scenario as users above, where I'm storing the resulting HTML in a separate div in my form. I don't really care that the HTML is malformed, as I clean it server-side.

Are you concerned about passing around broken HTML client-side?

Is there a fix for this? Seems like it catches everyone out first time round. I don't want to have to keep telling my users "make sure you toggle back to html mode before saving". They will see it as a bug and blame me about lost edits. I don't care about the possibility of bad html being formed client side.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

studiotemple picture studiotemple  路  3Comments

bbugh picture bbugh  路  3Comments

george-norris-salesforce picture george-norris-salesforce  路  4Comments

kikeso77 picture kikeso77  路  3Comments

isubasti picture isubasti  路  4Comments