Page MenuHomePhabricator

TemplateData editor allow text input fields to expand/autosize
Closed, ResolvedPublic2 Estimated Story Points

Description

Currently when editing parameter values, the sizes of the text input fields do not expand if the content is longer than is visible. This makes it very difficult to edit long descriptions or lists of values.

Switch all inputs for parameter properties to: MultilineTextInputWidget (autosize).

Event Timeline

Lena_WMDE renamed this task from Test instance: TemplateData editor text input, change to re-sizing to Test instance: TemplateData editor allow text input fields to expand.Oct 1 2020, 9:03 AM
Lena_WMDE set the point value for this task to 2.
ECohen_WMDE renamed this task from Test instance: TemplateData editor allow text input fields to expand to TemplateData editor allow text input fields to expand/autosize.Jan 13 2021, 10:33 AM
ECohen_WMDE updated the task description. (Show Details)

Note: was not implemented on test instance but we still want to implement in real life. Renamed to reflect that.

Lena_WMDE changed the point value for this task from 2 to 3.Jan 27 2021, 2:28 PM

Change 662696 had a related patch set uploaded (by WMDE-Fisch; owner: WMDE-Fisch):
[mediawiki/extensions/TemplateData@master] Allow input fields for parameter values to expand

https://gerrit.wikimedia.org/r/662696

The patch currently allows to enter newline characters into all these text fields. This was not possible before. Good news: Nothing breaks. The TemplateData JSON supports linebreaks just fine. Most of them show up as spaces in VisualEditor – which might not be what the user expects, but is at least not obviously broken.

We might need to discuss this for each field:

  • Name and aliases: Technically, parameter names (and aliases, which are just alternative parameter names) are actually allowed to contain newline characters. But this is really, really strange. I can't remember ever seeing this in a real-life template.
  • Label: While it's certainly possible to allow labels to contain line breaks, it feels odd for a label.
  • Description: Here supporting line breaks would possibly make sense. However, as of now line breaks are never rendered as such, but the description is always collased to a single line with spaces.
  • Autovalue: Line breaks work just fine. I actually suggest to officially mark this field with multiline: true, even if this should rarely be needed.
  • Default: It's probably rare. But when you think of the default as a value that could as well be entered by the user, it should accept newlines the moment the type of the field allows newlines (e.g. "string"). However, this heavily depends on how the default is rendered later. At the moment, it's a single collapsed line. This is actually a bug, as this field is currently the only one that's marked as being multiline – but it's never rendered as multiline.
  • Example: Probably similar to above.

However, I suggest to split the discussion which field should allow line breaks off to a separate task. For the purpose of this task let's stick to the current behavior and not allow line breaks in these fields.

Wikibase solves this by actively blocking the enter key: https://codesearch.wmcloud.org/search/?q=keyCode.*%3D.*ENTER&files=%5C.js%24&repos=Extension:Wikibase. When following this, make sure copy-pasting a text that contains newlines doesn't work as well.

However, I suggest to split the discussion which field should allow line breaks off to a separate task. For the purpose of this task let's stick to the current behavior and not allow line breaks in these fields.

+1, let's disallow line breaks for name, aliases, and label as suggested. I would allow for the other fields mentioned, good idea to start with disallowing and selectively allow in follow-up work.

It might take multiple levels of protection to catch newlines, for example blocking the enter key as mentioned, explicit validation, and stripping newlines whenever sanitizing user-generated input such as parsing from article content. In the Template Data dialog, it would be possible to also validate against newlines and show an error as for any other invalid value.

+1 to render vertical whitespace. Let's get this for free by supporting wikitext+html property values for the , with its known whitespace handling.

I can verify that it's already broken syntax, that it seems to be impossible to create a template invocation with a newline in the template name so there's a solid reason to disallow. I haven't checked the other fields, but seems safe to assume the same.

Sample text:

{{foo
bar}}
{{foobar}} # for comparison
  • Parser doesn't recognize this a template when viewing the page,

  • Source editor shows a problem,

  • Visual Editor doesn't show as a template either,

Don't add validation to the TemplateData parser yet, it has a really nasty way of preventing the editor from saving a page (anathema to how saving is supposed to work), but without displaying any visible errors. See T258790.

good idea to start with disallowing and selectively allow in follow-up work.

👍

such as parsing from article content.

There is not much that's "parsed". When there is no TemplateData information, the parameter names are parsed from the template page. Newlines are not accepted in this step. What we get from the article are the parameter values. These can contain newlines.

Let's get this for free by supporting wikitext+html property values for the , with its known whitespace handling.

This sentence misses something. I don't get it. What are "wikitext+html property values"?

newline in the template name […]

This might be a misunderstanding. We don't store the template name anywhere other than in the page title. Newlines are not allowed there. But this is core and unrelated to this extension.

Don't add validation to the TemplateData parser yet, it has a really nasty way of preventing the editor from saving a page […]

Fully agree. 👍

I update the patch. I created a new widget that's inherits the MultilineTextInputWidget with autosize and only one row. It also overrides the onKeyPress method to avoid newlines when hitting enter.

We could also add a general change listener to filter out new lines when someone does C&P with new line chars. Shall we?

Lena_WMDE changed the point value for this task from 3 to 2.Feb 17 2021, 9:30 AM

We could also add a general change listener to filter out new lines when someone does C&P with new line chars. Shall we?

For the record: We decided against adding a handler to avoid C&P new lines in the interface.

Change 662696 merged by jenkins-bot:
[mediawiki/extensions/TemplateData@master] Allow input fields for parameter values to expand

https://gerrit.wikimedia.org/r/662696

WMDE-Fisch moved this task from Demo to Done on the WMDE-TechWish-Sprint-2021-02-17 board.