Problem/Motivation

In all browsers, when editing a node that uses a select and that select has long options, the responsive layout does not work, and the right column is hidden in narrower browser widths.

Steps to reproduce

  1. Create a taxonomy list, add a term that will create a select option that is wider then the claro left column. The local example we had as 112 characters long!
  2. Add the taxonomy list to the content type
  3. Create / Edit a new of that content type
  4. Above 976px [the two column layout], Left column width is fixed by the width of the select input. resize the browser to see the right column fall out of the right side of the browser, until the

If I try limiting the select width using the browser console, it does not fix the layout. If I delete the select in the console, it does.

I am not sure how to make the select fluid width as it is in the browser widths < 976px [the single column layout], but this may not be a problem with the select, but with the grid?

After further research, this looks like the browser's regular behavior with a specific combination of display:grid and long select options that we can address with the specific code.

Proposed resolution

Select tag has been given a max-width 100%. Add the max-width: 60rem; to the form-element--type-select in the node form.

Remaining tasks

Review

User interface changes

Before

GIF

After

Fixed long select issue

API changes

NA

Data model changes

NA

Release notes snippet

Issue fork drupal-3403628

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

ice70 created an issue. See original summary.

swatidhurandhar’s picture

Status: Active » Needs review
StatusFileSize
new948 bytes

I can replicate this issue when select option has very long text, I have provided a patch to fix it. Here I have set the max-width of form type select.

needs-review-queue-bot’s picture

Status: Needs review » Needs work

The Needs Review Queue Bot tested this issue.

While you are making the above changes, we recommend that you convert this patch to a merge request. Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)

nitin shrivastava’s picture

StatusFileSize
new19.83 KB

@swatidhurandhar I am not able to replicate this issue.
Can you please provide steps with screenshots?

Working Fine from my end.
Example

swatidhurandhar’s picture

Status: Needs work » Needs review
StatusFileSize
new243.05 KB

@Nitin shrivastava Steps are mentioned in the description.
1) Create a vocabulary and create a taxonomy term in it which is at least 112 characters long.
2) Add the taxonomy in a content type and change the autocomplete to select list in manage form display.
3) Now add content in same content type, and now you can see the page is broken due to select list.

I have opened a MR for fixes.

needs-review-queue-bot’s picture

Status: Needs review » Needs work
StatusFileSize
new1.43 KB

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

nitin shrivastava’s picture

StatusFileSize
new21.69 KB
new16.63 KB

@swatidhurandhar Yes, I'm replicating the issue, but I believe this isn't a bug; it falls more into the category of a feature request. The width will adjust based on the character length of the taxonomy name.
Patch apply successfully.
Before Patch
Example
After Patch.
Example

nitin shrivastava’s picture

Status: Needs work » Reviewed & tested by the community
needs-review-queue-bot’s picture

Status: Reviewed & tested by the community » Needs work
StatusFileSize
new1.43 KB

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

shweta__sharma’s picture

I have checked the above screenshots and tried to replicate the issue. I don't think this is an issue i believe this is the select list default behaviour
@ice70 Can you share some screenshots where you are facing issues?

ice70’s picture

StatusFileSize
new19.73 KB
new15.19 KB
new10.54 KB
new9.7 KB

Hi @shweta__sharma

[with-select.png] shows the default layout with the taxonomy select that has some really long text.
A gap appears on the left side of the main edit column and the total page width becomes larger than the browser window creating horizontal scrolling. The right side of the page will not be visible from about 1024px, unless the user scrolls to the right shown in [hidden-right-side.png]

[without-select.png] shows the result of deleting the select object via chrome inspection. Once the select has gone, the two columns flow to the browser width and the page remains in the visible area.

When the layout collapses to a single column structure, the select changes to variable width and stays within the visible area [mobile.png] - I had a look around to see how this was working but could not see it to replicate on the higher browser widths.

Thank you for your help.

saschaeggi’s picture

This needs work as 34.3rem sounds like a pretty magical number to me

alex.87 made their first commit to this issue’s fork.

alex.87’s picture

Personally, I don't think this is an issue, it is just how the select list works across the browsers.

But in case I'm wrong I submitted a new MR with a small change. I changed `34.3rem` to 100% as the first one is not working well with the small devices.

alex.87’s picture

Status: Needs work » Needs review
smustgrave’s picture

Version: 10.1.x-dev » 11.x-dev
Status: Needs review » Needs work
Issue tags: +Needs issue summary update, +Needs screenshots

MR should be updated for 11.x as the current development branch.

Issue summary should be updated with proposed solution.+ before/after screenshots in the UI section. Please use full default issue template.

amietpatial’s picture

amietpatial’s picture

StatusFileSize
new1.45 MB
  • Tested on Screen Resolution Test:1366 X 768
  • OS - windows 11 pro
  • Browser - latest chrome
  • Data characters used 132 and 252.
  • Experiencing the addition of a horizontal scroll at the bottom that is adversely affecting the overall UX.
  • Attached screen recording
shweta__sharma’s picture

Issue summary: View changes

Added default issue template and updated IS
Thanks

shweta__sharma’s picture

Hi @amietpatial
As you tested the issue can you please test Merge request !5582? so that we can update the after-fix version into IS
Thanks

alex.87’s picture

Created MR against 11.x.

alex.87’s picture

Issue summary: View changes
Status: Needs work » Needs review
Issue tags: -Needs issue summary update, -Needs screenshots
StatusFileSize
new2.83 MB

Please ignore the !5582 and test the !6291. I can't close the !5582 because I was not the original creator of the MR.

Added Before/After screenshot. Updated summary to match the latest code that is different after pulling the latest 11.x.

kanchan bhogade’s picture

StatusFileSize
new19.6 KB
new72.86 KB

Hi
Tested on
Drupal version 11.0
Screen Resolution Test:1366 X 768
OS - ubuntu
Browser - latest chrome
characters- above 150
Test Result :
Unable to reproduce the issue, It looks good for D11 without a patch but I observed characters of long text overlapping on the search icon

Attached screenshot

Keeping in Needs Review state

alex.87’s picture

Kanchan Bhogade please use the testing steps from the IS. Create a new taxonomy, or edit the existing one, create a long term, and add it as a select list to the node, do not use the autocomplete.

smustgrave’s picture

Status: Needs review » Needs work

Not sure which MR is to be reviewed. Both seem to have failures though.

Gauravvvv made their first commit to this issue’s fork.

Gauravvvv changed the visibility of the branch 3403628-claro-long-select to hidden.

gauravvvv’s picture

Status: Needs work » Needs review

MR #6291 needs to be reviewed, as it has the latest changes. I have updated the MR, as earlier it was only targeting .form-element--type-select but this is happening on .form-element--type-select-multiple multiple select field as well. please review

amietpatial’s picture

sandeep_k’s picture

StatusFileSize
new161.76 KB
new146.13 KB
new206.72 KB

@Gauravvvv, I've tested MR- MR !6291 mergeable on-
Drupal version -11.0-dev,
Screen Resolution Test:1366 X 768
OS - Mac
Browser - latest chrome
Characters- above 112,

Testing Results
Before the patch, The field width was adjusted based on the character length of the taxonomy name, but the field was aligned with the other field in the form- added before result. I applied the patch as well & after applying the patch- the field size increased (which is not aligned with other fields) and while I re-arranged the fields in the form, some part of the field is also hidden under the Right section of the form- Added after results. Keeping this in Need review.

smustgrave’s picture

Status: Needs review » Needs work

MR 6291 appears to have failures.

alex.87’s picture

So in https://www.drupal.org/project/drupal/issues/3291549 we changed the layout-node-form to use `grid` instead of `float`, and a combination of a grid and long select is causing these issues, still looking for the best solution, but if I use flex instead of the grid all of the issues with nested elements are resolved.

nayana_mvr’s picture

StatusFileSize
new540.69 KB
new552.23 KB

This issue is not reproducible in Drupal core version 11.x. Tried with single select field and multiple select field. Please find the screenshots attached.

single-select

multiselect

But I noticed that last few texts are getting trimmed in the list if it is more that the width of the dropdown. I feel atleast some ellipses should be shown to indicate that there are more text.

_tarik_’s picture

I faced with a similar problem. In my case, we are using paragraphs with a select list with really long options. So, the select list visually breaks subforms.
Changes from comment #15 have limited usage. They can't help if your select list wrapper is less than 60rem(my case).
I think that we can solve the issue by providing a display grid on the select list wrapper(class .form-type--select) this change limits the select list to the 1fr width, so it won't overflow. However, this fix provides another issue. The display grid forces select lists to use the full width of the grid column. Hence, a small select list(say their options aren't longer than 5 characters) will take all available space. If we apply 'width: fit-content' straight to the select tag it solves an issue with the small select lists but brings back an issue with the overflow.
I can't recognize a better solution than a display grid for the select lists, but I can't find any CSS trick to apply it only to overflow items.
So for the moment, I can leave only a small tip for people who are faced with the same problem:

  1. Attach custom CSS library for Claro(if it is used as an administrative theme)
  2. Provide the display grid styles in the custom library for the wrapper for the select list that overflows.

FYI: The provided solution can trim a text of options. For the moment, it seems like some browsers may have an issue with the text wrapping, so it is better to use libraries for the select list customization.

niranjan_panem’s picture

Tested in drupal 11 claro theme, issue is reproduced,
I added the css style

.form-element--type-select>option,.form-element--type-select-multiple>option {
  text-wrap: auto;
} 

on file core/themes/claro/css/components/form--select.css
it wraps the long text without any trimming. Below is the screen shot after and before applying the css style.

Before applying the css style

screen shot of select option before applying css

After applying the css style

screen shot of select option after applying css style

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

quietone’s picture

Status: Needs work » Postponed

The Claro theme was approved for removal in #3576460: [policy, no patch] Deprecate and remove Claro.

This is Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.

The deprecation work is in #3576668: [meta] Tasks to deprecate Claro and the removal work in #3584638: [meta] Tasks to remove the Claro theme.

smustgrave’s picture

Project: Drupal core » Claro
Version: main » 3.0.x-dev
Component: Claro theme » Code
Status: Postponed » Needs work

Claro has moved to contrib