Filter configuration screen is broken when using Claro and Gin

Created on 16 March 2022, over 2 years ago
Updated 26 September 2023, about 1 year ago

Problem/Motivation

This is how the UI for configuring a filter currently looks in Seven

If you tick the "Expose this filter to visitors, to allow them to change it" option is looks like this

However, in Claro, the interface looks like this:

Note the dialog is not centered. It's not apparent from this screen shot but if you expand the Administrative Title fieldseet, there is no scrollbar to reach the expanded section.

If you tick the "Expose this filter to visitors, to allow them to change it" option it looks like this

Note the following configuration options are not available compared to the same screen when using the Seven theme:

  • Allow multiple selections
  • Remember the last selection
  • Filter identifier
  • Available filters
  • Administrative Title

Looks like Gin behaves the same as Claro

Steps to reproduce

Install module. Create a new view. Add a filter type of Populate filters and click on its link in the Filter criteria section of the views user interface to open up the configuration. Observe the behaviour mentioned above.

Proposed resolution

Make all themes behave as Seven.

Remaining tasks

All the things

User interface changes

Make all themes behave as Seven.

API changes

None

Data model changes

None

πŸ› Bug report
Status

Active

Version

2.0

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States SocialNicheGuru

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡¬πŸ‡§United Kingdom Eli-T Manchester

    Updating issue and setting priority to major because the UX when configuring an instance of this filter doesn't work very well when using what is now the default admin theme in core.

  • πŸ‡¬πŸ‡§United Kingdom Eli-T Manchester

    It looks like this is caused by the missing form elements being siblings in the DOM as the div that contains the well behaving form elements. This containing div has ID edit-options--(some id here). The edit-options div is autosized in script to fill the available vertical space in the dialog and so pushes the missing elements out of view.

    In Seven, the form elements that are missing in Claro are direct children of that edit options div, so they are contained within it rather than pushed down by it.

    If you manipulate the DOM in Claro and move the problematic elements inside the edit-options div, the form appears reasonable - the missing elements are again visible, and are now appropriately spaced from the left hand side of the dialog.

    I have no idea why at the moment the position of the form elements in the DOM has changed betweem Seven and Claro so not sure how to fix this yet; it seems possible this is a bug in core rather than this module.

  • πŸ‡ΊπŸ‡ΈUnited States josephcheek Provo, UT

    The culprit for this is dialog.views.js inside views_ui and a similar problem has been discussed in the drupal core buglist at https://www.drupal.org/project/drupal/issues/3161840 πŸ› Modal dialogue Views Messages breaks form usability Needs work . That particular bug has to do with messages displaying inside the modal, but the effect (and cause) is the same -- the JS code that is trying to maximize the space inside the modal dialog is not taking all elements into account.

    There is a patch in that ticket that adds support for counting message dialogs inside the modal, so perhaps that can be used as a starting point to fix this issue.

  • πŸ‡¬πŸ‡§United Kingdom Eli-T Manchester

    Adding πŸ› Modal dialogue Views Messages breaks form usability Needs work as a related issue

  • πŸ‡ΊπŸ‡ΈUnited States josephcheek Provo, UT

    Another wrench in this machinery is that claro, at least, has a custom twig template for the exposed filter form (when chosen as exposed, at least) that hard-codes all the form objects that go above the "fold" that dialog.views.js creates. It specifically puts these fields in the top:

    {{ form.form_description }}
    {{ form.expose_button }}
    {{ form.required }}
    {{ form.group_button }}
    {{ form.label }}
    {{ form.description }}

    {{ form.operator }}
    {{ form.value }}

    and then, later,

    {{ remaining_form }}

    which includes the $form['filter']. So another option is placing $form['filter'] inside 'value', or modifying the template (adding your own?) so that {{ form.filter }} is displayed before the fold.

Production build 0.71.5 2024