Autocomplete input in views exposed filters does not align with select and text inputs

Tested patch from #2 for in Chrome, FF, Safari, IE and result is OK

4 coding standards messages

Coding standards check must pass, see https://www.drupal.org/pift-ci-job/1614192

Rerolled patch #2 for test pass

I can reproduce issue if field has Help text

Also, need to resolve case when the form element has a long description.

Tested patch from #13 in Chrome, FF, IE, Safari for desktop and mobile and result is OK

patch at #13 worked fine for me. RTBC +1

Adding a max-width on bigger screens is really useful, but on the smaller ones doesn't makes sense the fields don't get the full width having enough space. So I'd suggest to add to wrap the max-width value into a media query.

We can certainly add the rule to media query but we don't set the inputs as width 100% at the moment.

I missed that we have that for text inputs but not selects. We should add the rule in a media query like @ckrina suggested.

Wrap the max-width value into a media query.
Review the patch attached screen shot for the reference.

Hi @komalkolekar please re-roll the patch. Fix lint error.

Working on this.

Here I have addressed comment #22.

Verified and tested by applying the patch #25.It looks good to me.Can be moved to RTBC.

Steps to test-
1. Go to admin site.
2. Go to admin/appearance.
3. Enable the Claro theme.
4. Go to admin/structure/views/view/content.
5. Make changes in View for content type.
6. Verify the content type page.

Before Patch -

After Patch Desktop -

After Patch Mobile -

This looks pretty good already! Thank you for working on this!

+++ b/core/themes/claro/css/components/views-exposed-form.pcss.css
@@ -35,6 +34,13 @@
+@media only screen and (min-width: 767px) {

The min-width should probably be 601px because the form elements are set as 100% until max-width: 600px.

Here I have tried to address comment #30.

Hello,

Tested patch #31 which works fine as per previous comment of @lauriii.

Screenshot:
Before:

After:

Thanks!

This looks great on Chrome and IE 11 but Edge could use some more work still:

@lauriii I checked the same page on IE Edge v83(browserstack) but not able to reproduce the above alignment issue as per #34

SS:

Thanks!

Here's an alternative approach which uses the line height and margins of labels to calculate the missing space

https://git.drupalcode.org/project/drupal/-/merge_requests/131 (also this is my first go switching from patches to merge request, apologies in advance if I've done something wrong in the process here ☺️)

Chrome -

IE11 -

Hi,

I would prefer the patch from #31
because it removes the margins on .claro-autocomplete which gives me trouble in #3194226: Add a form description toggle.
I tested the patch from #31 in edge 84 and edge 88, latest chrome and firefox esr 78 and I cannot seem to be able to reproduce the misalignment issue mentioned in #34, it also does not have the align-items issue in firefox mentioned in the mr.

If we remove that margin completely it causes issues elsewhere e.g.

(not that this looks perfect with the margin, but it's better 😊)

I've updated MR !131 with a fix for Firefox and the autocomplete breaking out of the container between 600px - 769px

Ah, I can see the issue now, this made me think, maybe we could add some background to .claro-autocomplete__message?

Before (with margin):

No additional margin, white background:

Btw. is it me or is only half of the throbber visible?

Applied patch #31 and it works fine. Adding screenshots below.

Before patch:

After patch:

RTBC +1

@volkerk That's a nice solution 👍 I think this might be better moved to a separate issue? I'm sure there's a bunch of other places in the UI we'd need to test this change, plus addressing the throbber visibility issue.

Hi @volkerk,

Patch #45 is applied and resolved the above issue but these is same issue on view content.
button is does not align with others.

Please have a look on attachment.

Thanks!

@djsagar which patch did you apply and in what browser is that?

I posted some feedback on the MR. I think that approach is good because it's getting closer to solving the root cause of this bug. ✌️

@lauriii thanks for the review! The collapsing margin is in place so that autocomplete fields that have no label are also aligned correctly

IIRC the margin was added intentionally to avoid #44. It might make sense to change the margin here, and fix it elsewhere on a follow-up since the problem caused with the loading... in edge cases where the label is very long could be less of a problem than the form elements not being aligned.

However I discovered another problem. If we remove the align-items: flex-end, buttons don't align with form elements without labels. But that doesn't work with descriptions and errors 🤷‍♂️

Discussed #52 with @justafish yesterday and we found out that the problem was with me testing the change by modifying markup in the chrome developer tools rather than actually changing the Views configuration.

We also did some testing related to the loading text and we discovered some edge cases where the label totally should be still displayed as inline-block. Therefore we agreed to remove the margin-top from the .claro-autocomplete element. We also did some manual testing to ensure it doesn't break any of the other use cases. We tested autocomplete in entity references (tags style and table drags) as well as autocomplete in the entity meta column. We also did some testing before and after and this change doesn't make the loading item look any more awkward with long labels than it already looks.

I think we should open follow-up for addressing #44 still. I also posted some very minor feedback on the MR.

All of my points on the MR were addressed. Moving to RTBC. Who wants to create the follow-up?

I've just created #3199351: Claro: review line-heigh usage accross components to address the line-height feedback.

And, If I’m not missing things, I can see the alignment fixed for autocomplete fields (with and without description) and working well with buttons. Here are the screenshots for Firefox:

And +1 on coming up with a solution for the loading overlapping problem into another issue too.

Here's the follow up for the overlapping text https://www.drupal.org/project/drupal/issues/3199601

Committed and pushed d9b41a883f to 9.2.x and 6bd92072ad to 9.1.x. Thanks!

Discussed with @lauriii and we agreed to backport to 9.1.x as claro is still experimental.

Seems like I tagged this accidentally with "Needs change record" when I meant to tag this with "Needs followup". Removing the tag because the follow-up issue has been filed and this doesn't need change record.