@Pginer-WMF, what do you think? Is this something we should fix, and what would be your preferred solution?

In T183484#3854740, @jmatazzoni wrote:

@Pginer-WMF, what do you think? Is this something we should fix, and what would be your preferred solution?

I agree that moving through the content inside an input field is not comfortable when the content is larger than the container. In general, we should provide enough room to accommodate well most cases, but we should also not be driven by the extreme cases like a user page with 4 levels of nesting or fictional dishes with a long name.

Overall, I think we can consider making a set of simple interventions to improve the situation a bit:

• Extending the input field to make it a bit longer, but avoiding to feel extremely long for regular uses. For example, making it 400px wide.
• And a tooltip with the full content to allow quick checks of the full page name.
• If we consider that the last part of long page routes is more meaningful, we can show the contents scrolled so that the final part of the string is visible. But since that implies hiding initially the namespace in those cases, which is also valuable information.

If we observe this becoming a frequent issue we can consider later more elaborate interventions.

More elaborate interventions

One possible solution is to replace the input field by an information element that represents the page once the page is selected. This is what was proposed originally in T172161, but not implemented. I copy the relevant mockups from the task below:

The search can be wider than the input field used for the search. Typing longer page names is not that of a problem since the user focus is on the end of the string.	Once the user selects a page, it becomes it's own information element that can grow up to a maximum size and text can wrap if needed.

Alternatively we can use smarter input fields, that start with a small size but grow as more content is added up to a maximum size. I'm not sure if this is easier to support with our current widgets (@Volker_E ?).

Another way to make inputs smarter would be to make them support different kinds of cropping. In this case, cropping the content in the middle could be more useful than doing it at the end since the final part is likely to be more meaningful in long paths (i.e., showing "User:Contraexemplo/Out...tes/December 2017" instead of "User:Contraexemplo/Outreachy/Daily note...").

Thanks for the solutions Pau. I've added the two simplest ones, for starters, to the Description.

(And thanks for turning me on to the Nashothek and to "oysters-saltfish-skate-sharks'-heads-left-over-vinegar-dressing-laserpitium-leek-with-honey-sauce-thrush-blackbird-pigeon-dove-roast-cock's-brains-wagtail-cushat-hare-stewed-in-new-wine-gristle-of-veal-pullet's-wings"!)

Change 399847 had a related patch set uploaded (by Sbisson; owner: Sbisson):
[mediawiki/core@master] RCLFilters: support longuer page names

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

@Pginer-WMF We've got one mechanism for auto-growing TextInput fields, so called 'autosize' MultilineTextInputWidgets, but they are only growing vertically.
Growing horizontally is normally not a recommended pattern as it can lead to major page reflow, as an example floats around such fields can break into the next line and so forth. Which might result in a jarring experience. It also might end up with an unsatisfying layout on mobile, when the main content slowly moves out of viewport.
I would see a horizontally extending field rather as extension for this specific problem when viewport allows it and where you've got full layout control (currently the elements are in a display: table construct) than as general OOUI widget approach.

Change 399847 merged by jenkins-bot:
[mediawiki/core@master] RCLFilters: support longer page names

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

Checked in wmf.15 - the case that was reported in the ticket is fully accommodated: User:Contraexemplo/Outreachy/Daily notes/December 2017- 54 chars long:

There are, of course, many examples that are longer e,g, 185 chars long: To authorize the Secretary of the Interior to take certain Federal lands located in El Dorado County, California, into trust for the benefit of the Shingle Springs Band of Miwok Indians.
However, I think that long titles are sufficiently represented when a user starts typing or when the whole title is pasted into the text box.

The one thing that can be improved: the tooltip text has underscores instead of white spaces. I checked for some of diacritical marks - they seem to be fine.

QA Recommendation: Product should weigh in

@SBisson, would it be a difficult matter to show the spaces between words as spaces instead of as underscores in the tooltip? See below. (If it's a simple matter, please make it so.)

In T183484#3873924, @jmatazzoni wrote:

@SBisson, would it be a difficult matter to show the spaces between words as spaces instead of as underscores in the tooltip? See below. (If it's a simple matter, please make it so.)

It's a bug in the widget we are using, as documented in T184181. I've submitted a fix but it may take some time to be accepted and deployed.