I tried to put the HTML5 'required' attribute on a textarea that had a wysiwyg on it but the form then became unsubmit-able. The same error occurs for both the tinyMCE and CKEditor.

The reason is because the wysiwyg hides the original textarea and only copies the value across to it in a javascript event handler when the form is submitted by the user. The problem is that the browser tries to validate the (hidden) underlying textarea as non-empty before it goes ahead and fires the submit handlers. It makes no difference that the 'required' textarea is invisible to the user - in fact at the moment that causes Chrome to report an error to the user.

This is very relevant since there is an ongoing HTML5 initiative to support these attributes on form elements as part of core. See #1174938: Natively support the HTML5 #required FAPI property

I'm not sure if this is something that is an in-built problem with the third-party wysiwygs themselves, or just the way wysiwyg.module integrates them into Drupal. I hope the latter - much easier to fix!

I'd love to supply a patch, but I'd have no idea where to start. Ideally the way wysiwygs work would change so as to update the underlying textarea as-and-when the user makes a change to the wysiwyg, rather than on form submit. This is because there will probably be other html5 attributes that it would be good to support (e.g. 'pattern' - allowing us to supply a regexp for the browser to validate input against) also.

Files: 

Comments

Since most (if not all) editors rely on the submit event in this way, it's not just a problem in Drupal.
I found http://www.tinymce.com/develop/bugtracker_view.php?id=4768 where a solution to this problem is requested.
If one is found, like using a different event, we should not have to change much in Wysiwyg for it to work in Drupal as well.

I don't know enough about the available events in HTML 5 yet to say if we can work around this in Wysiwyg or not. If there's an event firing under the same conditions as the submit event, but before form validation, we could perhaps detach the editors at that point and remove the submit handler.

Title:Incompatible with HTML5 'required' attribute - form becomes unsubmit-able[upstream] HTML5 "required" attribute prevents forms from submitting
Status:Active» Postponed

This needs to be fixed upstream in editor libraries.

I propose we take the same road to update the textarea's value also on the focus event instead of submit. It is really annoying you cannot make wysiwyg fields required because of newer browsers...

If anyone's interested in helping out to get this bug fixed for CKEditor there's an open ticket right here:
http://dev.ckeditor.com/ticket/8031

Now that CKEditor will be the main WYSIWYG editor for Drupal 8 I hope we can solve this issue rather sooner than later.

Priority:Normal» Critical

It looks like CKEditor has a lot more patience in fixing critical bugs than I do. For anyone who want's a quick workaround. Just add this behaviour to your javascript and required fields will pass the browser validation. The script just updates the editors value on "blur" event...

  /**
   * Update the value of a CKEditor field on blur or HTML5 validation could
   * fail on required form elements that haven't gotten the value yet.
   */
  Drupal.behaviors.updateWysiwygValue = {
    attach: function(context, settings) {
      if (typeof CKEDITOR != 'undefined') {
        CKEDITOR.on('instanceReady', function(instance) {
      var element = instance.editor;
      element.on('blur', function(e) {
            element.updateElement();
       });
        });
      }
    }
  };

Also if the user still complains why he cannot submit an empty field without getting a real notice that it's required. That may be because the actual textarea and its browser validation popup are not be visible.

You can just add an HTML5 "novalidate" attribute to the textarea to skip HTML5 validation entirely.

Took me a while to figure out this attribute was actually a thing...

Category:feature» bug

This is a bug, isn't it?

Looks like this will be fixed in CKEditor 4.2, which should land rather soon, see: http://dev.ckeditor.com/ticket/8031 and http://dev.ckeditor.com/roadmap
In TinyMCE however this doesn't seem to make progress: http://www.tinymce.com/develop/bugtracker_view.php?id=4768

This is not really a bug per se. It's more of a HTML5 spec/browser implementation fail. In Drupal 8 core we also implemented a work-around for this. See #1954968-34: Required CKEditor fields always fail HTML5 validation.

Status:Postponed» Active
Issue tags:+workaround, +html5, +Upstream bugfix, +Clientside Validation

So let's say it's a workaround for an upstream bug.
But either way, I think this should be unpostponed, because we can't wait for every single upstream WYSIWYG editor to fix this.
In D8 however, I believe we should remove the workaround from editor.module, see #2036573: Remove required field workaround.

Status:Active» Needs review
StatusFileSize
new1.6 KB

Confirmed that this is fixed in ckeditor since 4.2.

Not sure if the consensus is to wait for all upstream editors to fix this or not. I went ahead and ported (hopefully correctly) the patch in #1954968: Required CKEditor fields always fail HTML5 validation. I only tested it with ckeditor 3.6.6, 4.1.3 and 4.2.

Hello and thanks for your patch

in my case i did make a little change because if (field.attr('required')) returns undifined

So i did if (field.hasClass('required'))

i think that in my case i have a problem with my theme who does not write the attribute "required" as it would.
i have the same problem with Location module so i must add required as attribute my self.

May be someboy knows the reason of these problem???

thanks a lot for your help
Nora from Paris

I have tried to use privatemsg_nodejs module with ckeditor 4.2, and the form still does not submit, so it may need some additional fixes.

https://drupal.org/project/privatemsg_nodejs

Privatemsg_nodejs bug report:

#2033341: Cannot reply to post private messages using "normal" reply form with WYSIWYG/CKEDITOR

Issue summary:View changes

Updated issue summary.