- π¬π§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.