Views exposed filters with autocomplete are much wider than text filters

Hi @joaomachado,

I have added a patch on this ticket and attached screenshot also please take a look and let me know if there is any issue.

Updated test cases in the patch.

patch applied successfully on my machine.

~/Sites/drupal-9.0.0-beta2(9.1.x*) » git apply ~/Downloads/patches/views-exposed-filter-auto-complete-has-taxonomy-term-field-too-wide-3135137-7.patch                             amitsharma@MacBook-Pro-2
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
~/Sites/drupal-9.0.0-beta2(9.1.x*) »                                                                                                                                               

It looks good now on my local machine.

I feel we can move it to RTBC.

Hi @joaomachado

Please go to your project root folder and run this command: curl https://www.drupal.org/files/issues/2020-05-14/views-exposed-filter-auto... | git apply -v

Let me know if there is any issue

Reviewed this as part of Bug Smash Initiative.

Can we get a before screenshot of the field, relative to other fields in an exposed form.

Also, this is an autocomplete field, so is larger for a reason.

So perhaps this should be a feature request to make the size configurable?

Can someone do some git sleuth work 🔎 to work out when this was made 'size => 60' to see if it was by design.

If so, we need to make this a feature request to make it configurable rather than reverse that change.

--- a/core/lib/Drupal/Core/Render/Element/Textfield.php
+++ b/core/lib/Drupal/Core/Render/Element/Textfield.php

@@ -51,7 +51,7 @@ public function getInfo() {
-      '#size' => 60,
+      '#size' => 30,

Changing this in the base TextField is not the right fix for something in Views....

Added a screenshot, and updated title/IS.

It is indeed larger, but this applies to all autocomplete filters, not just taxonomy. The same is true for all autocomplete fields throughout core - when adding a menu link, redirect, URL on link field etc.

I don't know if this is a bug, lots of things in core have defaults that require a theme to override and it's not broken in any way, it's just a bit large.

Not sure whether we could make the change to apply *only* to views exposed filter fields, but certainly I would be opposed to changing it in the other places, like menu links and link fields, where often the extra space is necessary.

Work on this..

@larowlan as it's a bit wider as compare to title fields
and also if we will give Exposed form option config fields to manage field size, but on its process before rendering fields, and then core #process_default_value will modify as per Render FormElement.
So, we can achieve it by modifying autocomplete field size on before render of expose form fields.
@pameeela I have added code snippet with 'template_preprocess_views_exposed_form' to prevent changes in other places, like menu links and link fields.

I have attached Screenshot after applying patch file on local

Re check with code fix

I think I'm -1 on fixing this.

On existing sites this might break the layout they currently have, and adding an opt-in setting for this would add a new setting to Views that we can really do without.

I understand the reasoning behind this, and having a consistent layout is nice, but I don't think this is worth possible BC breaks.

@joaomachado the specific issue you’ve raised that the field is breaking smaller layouts is a genuine bug I think, it’s just not exactly what the original issue was about.

If we are saying the original issue won’t be addressed we can probably update this one to be about the display on smaller screens. Or could make a separate issue for that.

I've created #3192254: Views autocomplete input is too wide on mobile to address the CSS issue, as it only seems to be occurring in Bartik. The original request of this issue was for a much larger change in how this input displays, I think we can fix the CSS bug much more easily.

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.

Confirmed this issue on D10 by adding an authored by field to the content view.
Think we will need test to show this issue (but don't know what that would be)
Readding the screenshot tag for D10 before/after

Also think instead of $form[$key we can just use $element.

Patch for 10.1.x.
used $element instead of $form[$key