Dropbutton breaks when text is split to multiple lines

Thank you for reporting this bug! I will try to see how to fix this next week. Just for some more information, is the behavior where the characters are on separate lines as expected? Also, which language is this so I can try to reproduce this myself.

Thank you for following up on this issue. Which browser are you using?

@ckrina said

what makes more sense is that the right space with the arrow "just" gets the same height

I will do that to fix this issue.

Added new test for this that checks the content type manage form on /admin/structure/types.

The case with line-break can be found on Android and iOS screenshots.

I think the nested lists could be problematic for accessibility. Maybe we should take into account the proposed markup here #2278473: Simplify Dropbutton markup in line with our CSS standards since @andrewmacpherson gave positive feedback on that here: #1899236-67: Add new Splitbutton render element to eventually replace Dropbutton.

Moving back to NW for #13.

In case of anyone looking for fixes for the multi-line dropdown issue and open/closed dropdowns 'jumping' visually, I'm updating the patches from the related issue:
: https://www.drupal.org/project/claro/issues/3067262#comment-13290088
Might be a good practical fix for now.

Our current plan is that we fully rewrite Dropbutton, and fix this issue and the related #3067262: Dropbutton list size and content not consistent as well.

1. The markup we plan will be something that is proposed in #2278473: Simplify Dropbutton markup in line with our CSS standards.
2. The accessibility features that we need are here (with a fully-functional example).
3. @andrewmacpherson's notes and concers here: #1899236-67: Add new Splitbutton render element to eventually replace Dropbutton

#16 Patch Failed

#29 Please review the patch

Verified and tested patch #31.
Patch applied successfully and looks good to me.

Testing Steps:
# Goto: admin/modules
# Install Language and Interface translation module
# Goto: https://localize.drupal.org/translate/languages/zh-hans
# Download the file based on version
# Goto: admin/config/regional/translate/import
# Upload the file clicking on choose file
# Click on import
# Goto: admin/content
# Check the responsiveness UI
# User is able to see the Dropdown button is broken on a small screen.

Expected Results:
# Dropdown button should not be broken (size should be same)

Actual Results:
# Dropdown button is broken on a small screen when text is split into multiple lines

Looks good to me.
Can be a move to RTBC.

Updating summary to include testing instructions thanks to #33. Also updating priority and adding Stable blocker tag.

Adding Florida tag

Adding Florida tag

#31 Patch Failed

Thanks. The patch in #31 isn't relevant anymore because of the new MR in #37+. But the MR isn't applying to 9.4 either, so moving back to needs work.

[drupal-9.4.x-dev/9.4.x] [drupal-9.4.x-dev]$ patch -p1 < 793.patch 
patching file core/themes/claro/claro.theme
Hunk #1 succeeded at 637 (offset -3 lines).
Hunk #2 succeeded at 648 (offset -3 lines).
Hunk #3 succeeded at 1102 (offset -1 lines).
patching file core/themes/claro/css/components/dropbutton.css
Hunk #3 succeeded at 115 with fuzz 1.
Hunk #6 FAILED at 244.
Hunk #9 FAILED at 326.
Hunk #10 succeeded at 373 with fuzz 2 (offset 4 lines).
Hunk #11 succeeded at 395 (offset 4 lines).
Hunk #12 FAILED at 426.
3 out of 12 hunks FAILED -- saving rejects to file core/themes/claro/css/components/dropbutton.css.rej
patching file core/themes/claro/css/components/dropbutton.pcss.css
Hunk #1 succeeded at 69 (offset 1 line).
Hunk #2 succeeded at 81 (offset 1 line).
Hunk #3 succeeded at 116 (offset 1 line).
Hunk #4 succeeded at 166 (offset 1 line).
Hunk #5 succeeded at 217 (offset 1 line).
Hunk #6 succeeded at 234 (offset 1 line).
Hunk #7 FAILED at 313.
Hunk #8 FAILED at 353.
Hunk #9 succeeded at 379 (offset 5 lines).
Hunk #10 FAILED at 408.
3 out of 10 hunks FAILED -- saving rejects to file core/themes/claro/css/components/dropbutton.pcss.css.rej
patching file core/themes/claro/css/components/dropbutton.css
Hunk #1 FAILED at 332.
1 out of 1 hunk FAILED -- saving rejects to file core/themes/claro/css/components/dropbutton.css.rej
patching file core/themes/claro/templates/navigation/links--dropbutton.html.twig
patching file core/themes/claro/css/components/dropbutton.css
Hunk #2 succeeded at 305 (offset -2 lines).
Hunk #3 succeeded at 314 (offset -2 lines).
Hunk #4 FAILED at 330.
Hunk #5 succeeded at 353 with fuzz 1 (offset -19 lines).
1 out of 5 hunks FAILED -- saving rejects to file core/themes/claro/css/components/dropbutton.css.rej
patching file core/themes/claro/css/components/dropbutton.pcss.css
Hunk #1 succeeded at 90 (offset 1 line).
patching file core/themes/claro/css/components/dropbutton.css

Re-rolled MR-793 for 9.4

Thanks but it needs some fixes:

Drupal code quality checks failed.
To reproduce this output locally:
* Apply the change as a patch
* Run this command locally: sh ./core/scripts/dev/commit-code-check.sh
OR:
* From the merge request branch
* Run this command locally: sh ./core/scripts/dev/commit-code-check.sh --branch 9.4.x
--- Errors ---

1/3 ./themes/claro/claro.theme ...
1/3 ./themes/claro/claro.theme 1164.02ms

2/3 ./themes/claro/css/components/dropbutton.css ...
2/3 ./themes/claro/css/components/dropbutton.css 89.40ms X

3/3 ./themes/claro/css/components/dropbutton.pcss.css ...
3/3 ./themes/claro/css/components/dropbutton.pcss.css 64.67ms X
CSpell: Files checked: 3, Issues found: 2 in 2 files

Unknown variable var(--color-davysgray); was used, that's why custom commands failed. I have updated with var(--color-gray);.
Added interdiff for same. Please review.

Thanks for the update. Applies cleanly to 9.4 but not to 9.3 or 10.

[drupal-9.3.x-dev/9.3.x] [drupal-9.3.x-dev]$ patch -p1 < 3067697-46.patch 
patching file core/themes/claro/claro.theme
patching file core/themes/claro/css/components/dropbutton.css
Hunk #9 succeeded at 369 with fuzz 2 (offset -4 lines).
Hunk #10 succeeded at 392 (offset -4 lines).
Hunk #11 succeeded at 423 (offset -4 lines).
patching file core/themes/claro/css/components/dropbutton.pcss.css
Hunk #1 succeeded at 68 (offset -1 lines).
Hunk #2 succeeded at 80 (offset -1 lines).
Hunk #3 succeeded at 115 (offset -1 lines).
Hunk #4 succeeded at 165 (offset -1 lines).
Hunk #5 succeeded at 216 (offset -1 lines).
Hunk #6 succeeded at 233 (offset -1 lines).
Hunk #7 succeeded at 312 (offset -1 lines).
Hunk #8 FAILED at 357.
Hunk #9 succeeded at 375 (offset -5 lines).
Hunk #10 succeeded at 404 (offset -5 lines).
1 out of 10 hunks FAILED -- saving rejects to file core/themes/claro/css/components/dropbutton.pcss.css.rej

[drupal-10.0.x-dev/10.0.x] [drupal-10.0.x-dev]$ patch -p1 < 3067697-46.patch 
patching file core/themes/claro/claro.theme
patching file core/themes/claro/css/components/dropbutton.css
Reversed (or previously applied) patch detected!  Assume -R? [n] 

FYI I've been seeing this on the menus admin page where there are somewhat length descriptions on each menu, causing the "Edit menu" link to wrap onto multiple lines.

Rerolled for 9.3.x.

Here's how the menus look without the patch:

I also see this problem with Paragraphs / Entity Reference Revision fields.

Dropbutton collapsed:

Dropbutton expanded:

With the patch it has regressions:

Dropbutton collapsed:

Dropbutton expanded:

I'm inclined to say this "needs work"?

I'm noticing similar results, the backported patch on #49 is taking the full container height when opened, same is happening with the merge request and patch at #46.

After further testing, seems like the best candidate is the existing merge request (MR base branch needs to be updated for 9.4, currently 9.3).
It's working fine when .touchevents is present but it's not working with .no-touchevents plus is adding the regression mentioned in #50 for desktop.

Desktop:

.touchevents:

.no-touchevents (resized desktop):

Thanks for testing and providing direction.

To address @javi-er 's feedback and move this issue to 9.4.x, the faster way might be to add a new MR against the correct branch and not try to change the current one (9.3.x to 9.4.x). The reason is that only the person that created the MR can change the branch.

I fixed the issues on desktop and pushed the changes to the existing 9.3.x merge request, which will probably be closed, so I'm attaching also a patch against 9.3.x and a gif showing how it looks with different variants.

Thanks @javi-er! Would it be possible to provide that same patch but for 9.4.x then?

@ckrina yes! here's a patch for 9.4.x as well.

sorry wrong file, here's the right 9.4.x patch

I also made a patch for 9.2.x since I need it, I'm posting it as well in case it's useful for someone.

1. +++ b/core/themes/claro/claro.theme
   @@ -1070,6 +1102,37 @@ function claro_preprocess_links__dropbutton(&$variables) {
   +  // @todo Revisit after https://www.drupal.org/node/3057581 is added.
   

   I see this comment here about revisiting after https://www.drupal.org/node/3057581. And this issue is already in: should we change anything here or remove the comment?

2. +++ b/core/themes/claro/css/components/dropbutton.pcss.css
   @@ -317,19 +310,39 @@
   +  background: #fff;
   

   #fff should be replace by var(--color-white).

@ckrina, just replaced the color definition and removed the @todo you noticed since that change is now applied with the change in the other ticket as you mentioned.

Attached are updated 9.3 and 9.4 patches.

Simplifying the issue title a little, because it is not dependent upon the viewport size, and added a second set of steps to produce them.

Resolved CSpell errors & added an interdiff as well.

Thanks @yogeshmpawar ! but I think that var(--color-davysgray); needs to change to color: var(--color-gray-800); per https://www.drupal.org/project/drupal/issues/3154539

Attaching new patches.

Fixed CSpell errors.

Back to needs work due to "Drupal code quality checks failed."

Sorry for spamming with patches, re rolling to fix commit code checks.

While looking at why tests are failing, I noticed that at /admin/structure/views/view/who_s_online the "Duplicate Who's online" drop-button was broken because the sub items on this particular element were inputs instead of links, I updated the above patch once again (just for 9.4) to address this.

Regarding the failing tests, I'm not sure why it's happening, the test is returning "Element matching css "#views-display-extra-actions.dropbutton--small" not found." at /admin/structure/views/view/who_s_online , however it's present, maybe it's a cache issue? this seems to be the last thing blocking this patch.

This is issue is a bit funny, and IMHO should not be a stable blocker. I'm doing a mini-sprint with @lauriii and @ckrina we walked through this issue.

In the original summary:

In/admin/content, the operation button is broken a little

From what I can tell, this issue was created as a minor note, but was then bumped to Major and a stable blocker in #39 based on the potential that the dropbutton can obscure other dropbuttons.

However @lauriii and I could not get this edge case to happen with newly-installed Drupal (standard profile) and simplified Chinese. We can edit the text of the page in Chrome Developer Tools to make it happen though.

So to recap, there’s the possibility of the dropbutton obscuring other dropbuttons, but without editing the HTML in dev tools, we cannot get this to happen. To me, this is a fairly extreme edge case.

The reason that this happens is that we hard-set the height of the dropbutton (~24px-ish). We do this because of nature of the HTML structure, which is not optimal. If we get into refactoring the HTML, we get into the territory of the current work that’s happening at #1899236: Add new Splitbutton render element to eventually replace Dropbutton

My suggestion (which was agreed with by @lauriii and @ckrina on a zoom call) is to set a minimum width of the dropbutton (@ckrina suggested 6rem), which would prevent even extremely long simplified Chinese strings from obscuring the next drop button. This is more of a bandaid, IMO, but it does fix the problem in all but the most extreme, extreme (to the extreme power) scenarios, and will suffice until the splitbutton is implemented.

Here's an image after I edit the text with dev tools to show that the dropbutton can obscure the next drop button.

Updating summary

Here is the 9.4.x with the CSS properly compiled.

Before patches, dropbuttons have the potential to overlap, but it seems the extremely long dropbutton is the one that gets clipped rather than it's neighboring normal-length dropbutton.

Long dropbutton hovered:

Overlapping normal dropbutton hovered:

After patches, the dropbutton's height is dramatically reduced even though the content is the same:

RTBC!

Committed 285c13a and pushed to 10.0.x. Also committed to 9.4.x. Thanks!