Wysiwyg-editor: html mode does not save changes

[rwaters71]

Editor does not let you save any changes when you submit the form in html mode:
1) changes are not being saved - it seems impossible to make any changes to urls or image tags and save the contents.

2) html code is being changed (wrapper elements and classes added for images and links, etc.).

(in my case a textarea, inline mode is disabled, "Show HTML" mode, tested in both IE11 and Firefox 30)

[stefanneculai]

Thank you for reporting it. We'll check and fix shortly.

[rwaters71]

Thanks for working on this Stefan !

Also, further to this, once you make any change in html mode and switch back to wysiwyg, it is very hard to get the cursor to focus in the textarea. (only happens if you actually focus in the html mode textarea, or make any change in html mode).

[stefanneculai]

What browser (name, version) and OS are you using?

[rwaters71]

The secondary smaller problem (no cursor or focus after html-mode edit) only seems to affect Internet Explorer (version 11, Windows 7 Ultimate x64 in my case). It does not affect Firefox 30 or Chrome. The original issue seems browser-independent.

[stefanneculai]

1) It makes no sense to save the content while you're editing HTML. Save should be done only wen you're not in HTML mode.

2) Wrappers are removed when the content is saved. We improved the links and images and now fewer wrappers are used. Your problem should mainly be fixed. Could you please check?

IE Issue: not tested yet.

[rwaters71]

Thanks for the improvements Stefan!

1) It is sometimes necessary (for me) to edit HTML directly. I believe that an editor in HTML mode should behave similarly to a plain textarea, i.e. it should save changes that the user makes. All other editors I have used seem to behave this way.
With the current Froala version (as of today), if I edit code directly, even after going back to WYSIWYG mode, not all changes are being saved. For example, if I have added an image, in HTML mode the tag is of the type: <img ... src="/images/123.jpg">, even after changing the contents of the src="...", the changes are not being saved (regardless of whether you switch back to WYSIWYG mode or not). Only changes to style/alt/class are saved, and only if I switch back to WYSIWYG mode, which is somewhat counterintuitive. What If I was to paste a block of html code, I can't be sure of what will save this way.

You are correct that it is more common to save after you see the results in WYSIWYG mode. However, if you have a form with textarea (Froala) and submit button, users would expect the contents to save if they submit the form without regard for the current editor mode. It is counterintuitive not to save the changes that have been made if the user submits the form.

2) This seems fixed, thank you! I'll do some more testing, but it seems to behave well (the extra classes f-img-wrap, f-link, etc. are not added anymore).

[richoid]

Referencing rwaters71 comment:
"It is sometimes necessary (for me) to edit HTML directly. I believe that an editor in HTML mode should behave similarly to a plain textarea, i.e. it should save changes that the user makes. All other editors I have used seem to behave this way."

ABSOLUTELY!!!

A main reason I'm trying alternative editors is to find one that is predictable. I want to write freely and get minimal unstyled text. I want to paste and get minimal unstyled text. Then I want to style it. If I style it, I want minimal modification: bold ads strong tags, italic adds em tags, if I color it, I want style="color:#000000" added to a span. Simple. Never add font sizes unless I add them, myself.

This seems so obvious, yet I see WordPress' with TinyMCE wrecking the html tab, so I can't see <p> and <br>. And I see Froala adding <p><br><p> in front of my content and font sizing and I just can't understand this. Maybe you need to add a "Leave this damn stuff alone" tab. I'll pay for a developer license for the first editor that has that.

[stefanneculai]

@rwaters71 The src of the image is being saved if you change it in HTML mode and then switch back. The following list of attributes is saved ('title', 'href', 'alt', 'src', 'style', 'width', 'height', 'target', 'rel', 'name', 'value', 'type', 'colspan', 'rowspan') and all 'data-*' attributes are saved. If you believe there is any other attribute that should be saved and is not here let me know. You should consider disabling the submit button while you're in HTML mode or simulate leaving the HTML mode and then submit the normal form (we'll add shortly this by default in the editor).

@richoid Give a try to the version from this repo. You will see that the output is cleaner than any other editor. No <font> tags and all styles are merged in a way that you won't get unnecessary tags. The <p><br><p> is necessary for the moment, we may remove it in the future. What do you mean by font sizing?

[rwaters71]

Stefan,
On the image tag, if I edit the src=.... in html mode, the changes are not being saved for me, even after changing back to wysiwyg before submitting the form.

Ideally I would like to also be able to save in html mode (without Froala interpreting/changing the html input), that would prevent/mitigate any possible future peculiarities.

[stefanneculai]

Look at https://www.dropbox.com/s/wnqmv6hwg30q7n1/edit%20src.mov. The editor saves the src when you go back to HTML mode.

It makes no sense to save the HTML without the editor interpreting the html input and we'll not change that. If you want such behavior you can customize the editor to work that way. As I said on another issue, there should be no reason why to use the code view (people who use the editor aren't developers - they don't know HTML!!!) or if there is one it should be eliminated.

I consider this issue closed.

[rwaters71]

In my case (Froala as textarea with submit button): after you edit the img src, the image seems to change as per your video (you see the new image in wysiwyg mode), however, after submitting the form the change is not reflected for some reason (the old url is being saved, other text changes are not being saved). This is after switching back to wysiwyg mode and clicking submit, as per your suggestion, and seems browser independent.

[rwaters71]

After a bit further investigation, seems my problem may be related to "afterRemoveImageCallback: function ($img)" - switching to html mode with an image in the area throws an error:
TypeError: $img.attr is not a function
this.options.imageDeleteParams = {src: $img.attr('src')};

[stefanneculai]

a391bca9e6d4a490129e45aad6eea7ab727ad32b closes the HTML view and does a sync when when you're in HTML mode and submit a form.

[eneifert]

@stefanneculai "It makes no sense to save the HTML without the editor interpreting the html input and we'll not change that."

My client has asked me to help make some changes to the page that they are unable to do themselves. So I jumped in the html editor and added some code. But as soon as I hit save it dramatically changes the html I just entered. I have attached the before and after sources so you can see what happens.

I am trying this editor out but I want you to know this is a big deal. If I can't fix the HTML then I think that is a big sign that there is something wrong with the HTML editor.

Before: https://gist.github.com/eneifert/8f23fbd79f01fdc54575
After: https://gist.github.com/eneifert/847c21b2300487a17596

[stefanneculai]

@eneifert if you use the master version it will work fine.

[beyondcreed]

Just curious has this ever been fixed so you can actually save in HTML source view instead of flipping back to rendered view and saving? Right now it's sort of a bad UX to have save button disabled for HTML source view and forcing them to switch to rendered view before saving. If you look at other editors out there, textangular, summernote, tinymce or cms systems using html editors like wordpress, drupal, etc. they all allow user to save data while sitting inside HTML source view. I understand you wanna enforce filters/transforms on the data so editor can parse it out correctly and render, but wouldn't it make more sense to somehow be able to bind these routines while editing in HTML source view. That way when save button is clicked you could simply run the filtering/transform on the content in the text area and correct what needs to be corrected thus allowing the capture/save without having to flip between the two. Alternatively maybe a simpler solution would be to have a config switch/toggle (so you can maintain backward compatibility) that allows data capture/save (i.e. override switch) and then editor can simply fetch content back and filter it when either: 1. page is fully loaded or 2. flipped between the modes (source to render). Most of the times server side implements sanitization/filtering process as you cannot rely on client to handle this due to security concerns. Right now it would appear that the only sane way to get around this restriction is to have separate text area not connected to editor where raw source is shown and then another button where editor can only display rendered mode if such button is clicked, these could then be kept in sync somehow via backend. It's either this or hacking the core to allow data capture at raw source level.

[stefanneculai]

@beyondcreed I agree with you that switching to text view when saving is a bad UX. Last commit fixes that and it doesn't switch back to the text view on save. However, it will still do all the cleanup for consistency with the options the editor is initialized with (htmlAllowComments, htmlAllowedAttrs, htmlAllowedTags, etc.).

[shidhu40]

Editor automatically delete <form> tag in html mode

[stefanneculai]

If you're using the editor inside a form then it won't work to have another form tag inside the editor unless you use the iframe: true option.

[ivanyshak]

@stefanneculai
Same issue:

• when i'm trying to save something from code mode it doesn't save;
• in console i get next error: The given range isn't in document;
• check screencast: https://drive.google.com/file/d/1uRmh_kt_7o8D1s5UoT6Pdh9TsskPPzJz/view

[stefanneculai]

@zvermike Do you think it would be possible to make a jsFiddle to highlight the problem? That would speed-up things a lot. Here is a basic jsFiddle you could use as a starting point: https://jsfiddle.net/froala/wc5c3jhk/.

[EmanuelGenially]

@stefanneculai
Hello! I have same issue.

When i’m trying to save something from code mode, Froala doesn’t save it.

To save changes, I need to disable (close) code mode. This is not the behaviour I expected, I thought it will save also from code mode.

[silver-software]

How can I save the styles of images in Froala Editor?

[dchase-sir]

@stefanneculai isn't it better just to say it doesn't support it, than to say it makes no sense? In my case, the editor is seated in a modal dialog with an OK and Cancel button, and they edit HTML as part of their normal job.. So they switch to code-view, make their changes, click my "OK" button, then freak out when the changes aren't in their newsletter... Is there something I can trigger with my OK button? Maybe I can use JQuery to trigger the code button twice, and wait for it, then save the contents of the bound variable?