Text fields not big enough

Can the majority of fields be changed to use ?

Changed to use what?

A textarea could be used, but would have to be filtered for line breaks. People have a tendency to want to hit the "Enter" key in textareas if a line gets too long.

Sorry to kind of hijack this issue, but I thought it was about my exact problem given the title and since it ties in so closely, I thought it would be OK. Apart from just an inconvenience, I was actually having trouble entering all information I wanted in the feature policy header. My customer asked to set this as restrictive as possible, and unless I misunderstand how the header works and there is some sort of "catch all", I need to enter every possible feature with a 'none'. That won't fit in the field (as in, is longer than the allowed length). I adapted the issue summary.

Should read up on how Feature Policy works (and not hijack threads...):

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy

The values * (enable for all origins) or 'none' (disable for all origins) may only be used alone, while 'self' and 'src' may be used with one or more origins.

Also, if you wanted to enter each one individually, it's not that long of a list. Mine is much longer and can easily fit all of them: https://www.smashingmagazine.com/2018/12/feature-policy/

OK, that is a different problem then, because AFAICT the module only allows a single value.

The values * (enable for all origins) or 'none' (disable for all origins) may only be used alone, while 'self' and 'src' may be used with one or more origins.

This must be unique to Mozilla (or at least not a universal truth) because this page from Google even gives an example mixing 'none', 'self' and *: https://developers.google.com/web/updates/2018/06/feature-policy

Not sure what you mean that the module only allows a single value. It's a textarea. Right from the code:

  // From-Origin destination
  $form['seckit_fp']['feature_policy_policy'] = array(
    '#type' => 'textarea',
    '#title' => t('Policy'),
    '#default_value' => $options['seckit_fp']['feature_policy_policy'],
    '#description' => t('Specify the policy to be sent out with Feature-Policy headers.'),
  );

I think you are misunderstanding my other comment. Per the policy, you can use "none" by itself for each item. That is not Mozilla specific.

We ran into this issue with a client a while back. We simply converted the input fields to textarea's as mentioned above. While this might not be the ideal UX for this solution it worked for our scenario. We've had no issues with additional formatting injection and was able to exceed the 1024 character limit.

I agree with this request. I need to be able to enter several domains for some of the Content Security Policy fields, and it would be much easier and more readable if all of these fields were textareas, so that you could put each domain on its own line. Then you could just strip out the newlines when you create the header.

Instead of changing all of these inputs to textareas, why don't we increase the maxlength to something less restrictive?

AFAICS Drupal's formapi doesn't have a maximum value for maxlength which is likely because there is no maximum in the spec:

• https://html.spec.whatwg.org/multipage/input.html#the-maxlength-and-minl...
• https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#...
• https://stackoverflow.com/questions/26469152/why-is-the-default-max-leng...

Per that last thread, it looks like browsers implement a very high limit in practice, but seems like we could - e.g. - add a zero to the end of the maxlength without breaking anything.

I am not a UX expert, but I'd think it best not to add 13 textareas to the already very busy admin form.

I did have a look at using a textarea but adding some attributes to keep the form element roughly the same size by default, but I think we'd then need to get into messing with CSS (e.g. textareas seem to default to width: 100% and the grippie div below them matches).

Example:

   // CSP default-src directive.
   $form['seckit_xss']['csp']['default-src'] = array(
-    '#type' => 'textfield',
-    '#maxlength' => 1024,
+    '#type' => 'textarea',
+    '#attributes' => array('rows' => 1, 'cols' => 68, 'style' => 'width: auto'),
     '#default_value' => $options['seckit_xss']['csp']['default-src'],

That seems to work with default "Seven" admin theme, but the grippie div would need some extra CSS, and it'd almost certainly be better not to add a style attribute to the form element.

It's not too hard to get the CSS to work for Seven etc.. but we risk making a mess in other admin themes.

On the other hand, just changing all the fields to textarea makes quite a visual mess IMHO.

All that said, I'm quite inclined to just add that zero to the #maxlength for each textfield.

Any objections?

Had to give the textarea + CSS route a try.

I'm fairly happy with this in Seven, but haven't looked at any other admin themes.

There are other textareas in the seckit admin form that we could add the rows=1 attribute to for consistency.

Increasing the maxlength would be a simpler change than this, but it's not very friendly UX.

Tweaked to make the same change to most of the other textfields / textareas in the admin form.

I've not changed the textfields which are "max" values expecting small integers.

Added a test for a long value being submitted for a CSP directive in the admin form.

I'll commit this patch if tests pass.

Per #4 one concern here is that users may enter line breaks into textareas and that's likely to cause problems with most if not all of the fields we're changing here.

We could add validation to raise an error if any of the textareas contain line breaks?

That might be better than adding to the submit hook to silently remove line breaks - although that's what D7 does to textfields:

https://git.drupalcode.org/project/drupal/-/blob/7.94/includes/form.inc#...

Hi, I believe allowing line breaks would be great advantage especially if this change would also be ported to the D8+ versions.

It would allow people to group entries on different lines but more importantly, make it possible to have entries on separate lines in the configuration files.

Especially on larger sites, where multiple features are developed and tested simultaneously, multiple feature-branches often include a different change on the same line (e.g. adding an item to script-src) in the configuration file (seckit.settings.yml) which results in harder to fix merge conflicts.

Okay, but we'd then have to remove the newlines when processing the directives, unless I'm missing something?

I can see the advantage for D9+ when checking config into version control, but I think that's out of scope for what we're looking at here.

I'm trying to get this "small" change done in an attempt to prepare a new D7 release :)

Here's some validation for the textareas that shouldn't contain newlines (assuming their values are going straight into http response headers).

Plus a test of that validation.

I think I'm done for now; will commit if tests pass.

@Dozz your suggestion of allowing newlines in some fields likely makes sense especially in the D9+ branch. I think that should be a followup issue though. Thanks!

Marking this as fixed for the 7.x-1.x branch. Thanks!

A followup issue should be filed for 2.x (and perhaps that should accept + process newlines in some of the inputs).

Created #3340072: Text fields not big enough