contents of dropdown button go to the left and can be off the visible page

@paul121, @sashaeggi

Looking closer at the code, this makes more sense now... when the dropbutton is on the "right side" of the screen, we want to set right: 0, but when the dropbutton is on the "left side" of the screen, we want to set left: 0. Perhaps this should be an option for the dropbutton render element? I know that will all be changing soon, but maybe something to consider in the new implementation?

This is exactly the issue. The current selector and property are 100% correct:

[dir="ltr"] .dropbutton .dropbutton__items {
  right: 0;
}

...if the dropdown button is only ever positioned at the right edge of a container.

The only real solution I can see is to write context-aware selectors something like this:

[dir="ltr"] .dropbutton--right .dropbutton__items {
  right: 0;
}

[dir="ltr"] .dropbutton--left .dropbutton__items {
  left: 0;
}

Why can't the dropbutton be made to be the size of its largest item?

We've been observing this same issue. The original MRs no longer apply, and they appear to have no extant use since we're seeing position: fixed applied via JS, presumably from a completely different part of the theme. We'll have to dig into this in a bit more depth to see how the dropbutton styles are applied at runtime.

I have a very similar issue since 3.0.0-RC12. Looks like a regression from 🐛 gin-table-scroll-wrapper hides drop down options if they expand beyond container Fixed , where the dropdown handling was moved to JS.

The issue for us was the fact that in CSS, dropbuttons on node forms are still left-aligned while they are right-aligned everywhere else.
The new logic in dropbutton.js did not account for this fact, and always calculated a right-aligned position.

The new MR fixes that.

Applying the patch from MR !459 solves the problem of dropdown items being off-screen to the left. In my case there is still a problem with not all items being visible. It takes scrolling to show all the items in the dropdown - see attached video.

mrshowerman → changed the visibility of the branch 3242554-form-actions-fix to hidden.

mrshowerman → changed the visibility of the branch 3242554-contents-of-dropdown to hidden.

@mscieszka, this has been fixed with the latest commit.
It was caused by a wrong calculation of the dropbutton menu's height, due to upstream styles from Claro.

Thank you, I can confirm that it is now working as expected.

I have also verified the MR-459 and tested it on Drupal version 10.4.x and Minimal Lite 8.x-3.x. The changes are applied properly and I have added the before and after screenshots for reference. +1RTBC

It works for selecting a paragraph type, but not on the Module builder form:

nayana_mvr → changed the visibility of the branch 3242554-form-dropdown-left-alignment to hidden.

nayana_mvr → changed the visibility of the branch 3242554-update-form-dropdown-left-alignment to hidden.

In the code MR-459, can we use el.closest('form') instead of el.closest('.node-form')? It fixes the issue mentioned in #22 🐛 contents of dropdown button go to the left and can be off the visible page RTBC but I'm not sure if it is the correct solution.

Ok. Thanks @mrshowerman for the clarification. I will close that MR. Need to check some other solution for Module builder form.

@joachim: by default, Gin only left-aligns dropbuttons within a .node-form wrapper.

Maybe we could provide a more general way of declaring the alignment, e.g. through a dedicated CSS class? But that would perhaps require a change in core.

> by default, Gin only left-aligns dropbuttons within a .node-form wrapper

Why?

Buttons in forms will typically be left-aligned. There's nothing special about node-forms.

Why?

I don't know, that's only my interpretation of the CSS code.
I think this @saschaeggi should reply to this question. The alignment changes were made in #3196723: Dropbuttons auto-close on certain admin pages → and #3224124: Dropbutton actions form element is styled incorrectly → .

I applied the patch, and it worked fine, but this occurs when the dropdown is at the top:

I'm seeing the same results as @rpayanm with the patch from MR 459.

I've applied both the MRs as patch and MRs have been applied with no errors. After applying MR!470, the issue of dropdown button has been resolved successfully for node-edit-form but the changes made in this MR is breaking the dropdown button alignment styling for all other form also as it is targeting const leftAligned = el.closest('form') || false;.

On applying MR!459 as patch, I can confirm the mentioned dropdown button issue has been resolved successfully and no other form styling has been impacted by the changes made in this MR.

I didn't get the issue mentioned in comment #31 🐛 contents of dropdown button go to the left and can be off the visible page RTBC for both the MR!470 and MR!459. I've added the paragraph reference field at both top and bottom, and the dropdown button is working fine with no style break for both the MRs.

I've attached all the before and after screenshots for both the MRs for reference.
After reviewing and testing the MR!459, RTBC +1. And I'm changing the issue status to Needs Review for now. Anyone else can review the changes and can move the issue status to Review & tested.

Tested on:
Drupal 10.2.5
Gin: 8.x-3.x-dev

I got the issue on
Drupal v10.3.1
Gin Admin Theme 8.x-3.0-rc13

NW. I get this issue on:

• Drupal v10.3.1
• Gin Admin Theme 8.x-3.0-rc13
• Node edit screen → "URL Redirects" sidebar → "Edit" redirect dropbutton

I've tested patch https://git.drupalcode.org/project/gin/-/merge_requests/459.diff

And the solution is better but not perfect. I see two issues:

• Before, the dropbutton was right aligned, now it seems to be left aligned.
• The fact that it is left aligned means the right side of the drop down is still offscreen.

Before:

After:

I've fixed the alignment issue for the sidebar dropbutton. Please review the MR. Attaching screenshots for reference.

Verified the changes of MR-459 and it fixes the issue mentioned in the ticket description and #36 🐛 contents of dropdown button go to the left and can be off the visible page RTBC . Attaching screenshots for reference.

But it doesn't addresses the issue mentioned in #22 🐛 contents of dropdown button go to the left and can be off the visible page RTBC

For that is it possible to set a max-width to the ul.dropbutton__items item say for eg., 175px and word-wrap: break-word; white-space: normal; to input.button items. I tried it in my local but it was affecting the top value of the dropdown.

Left position is better, but not sure if this is a regression. MR-459 patch tested.

Same issue here. Tested MR!459 in 10.3.

I've tested MR#470, and I see the issue with the Header/Title of the page on Paragraph Library page (/admin/content/paragraphs/add/default) when using the submodule paragraphs_library

man-1982 → closed merge request !488

Added fixes in css styles and re-worked some JS behaviour.
Ready to review.
Tested on desktop and on mobile too
I've made small movies as a proof, that MR works and can be merge

i used @andreastkdf `s MR and added my changes.
@andreastkdf you've done great work. Thanks

man-1982 → closed merge request !489

@man-1982 is it possible to provide a patch on the latest release? The changes from the merge request don't apply as the latest release is already some commits behind.
I tried to create a patch bit it kept on failing to apply because of all changes.

@andreastkdf Hi!
Could you take a loot to your lates commit. I see we can't pass some frontend

@kevinvb Hi!

is it possible to provide a patch on the latest release?

It's really interesting and i'm not clear understand how it's work, but i used

"patches": {
            "drupal/gin": {
              "[3242554] Contents of dropdown button go to the left and can be off the visible page": "https://git.drupalcode.org/project/gin/-/merge_requests/459.patch"
            }
        } 

in my composer.json and i can see the patching result in my code. (of course i've deleted gin folder and composer.lock before composer install)
However i see some errors in console during composer install executing, but again i see patch was applied.

[Exception]                                                                                                                                                                   
  Cannot apply patch [3242554] Contents of dropdown button go to the left and can be off the visible page (https://git.drupalcode.org/project/gin/-/merge_requests/459.patch)!                                                                                                                                                          

Also i see Andrea Kostakis (@andreastkdf) added lots of changes in his last commit.

Hi @kevinvb
I've noticed really odd situation. When i tried to apply patch from https://git.drupalcode.org/project/gin/-/merge_requests/459.patch it didn't
work.
However when i applied patch from https://git.drupalcode.org/project/gin/-/merge_requests/459.diff. it were applied without any issue.
I use composer for applying patches.
You can see result on the picture

thanks @man-1982 for sorting out the commit, I just rebuild the assets to make sure all the generated js and css was up to date. It looks like your sorted it out, sorry for the confusion,

About applying the MR as a patch, you can indeed use the plain diff ( documentation here - note the difference between the two options on the MR (Diff and Patch) and what to use → ), so you basically either:

• Use this to your patch on composer (as you did already): https://git.drupalcode.org/project/gin/-/merge_requests/459.diff
• Or, while on the MR page from the Plain diff button in the download menu of an MR. and add a local .patch file with the contents of the diff you downloaded and apply the patch with composer

Ok I was able to patch it with https://git.drupalcode.org/project/gin/-/merge_requests/459.diff
If I download the diff and try to use a local copy it doesn't apply for some reason. I guess it is maybe related to a newline being added to the file but not sure. I normally always download the diff and store it locally because having direct links to a merge request could lead to unexpected behavior as you never know which version you get while performing composer update.

I tested the functionality and it works. You do however get a very long scroll bar now if the button isn't open and the paragraphs field is the last element it a huge whitespace. Also visibile in the video but I guess it's the only way to solve this issue.

Hi everyone,

You do however get a very long scroll bar

@kevinvb you are absolutely right. But in my defenss, i did try a few other approaches (position:static, relative and one more), but this was the only one that actually only worked for me.
@kevinvb i'm alway open for new idea, so if you've got one please let me know. It would be perfect.

@andreastkdf (Andrea Kostakis) special thanks to you, you've put a lot of work. Great job Andrea!

Thanks everyone for working on resolving this issue!

You do however get a very long scroll bar

Can we work around that with setting a max-height and make the content scrollable which I think I'd prefer. See also https://git.drupalcode.org/project/gin/-/merge_requests/486/diffs

I left some code styling improvements in !459

mrshowerman → changed the visibility of the branch 3242554-update-form-dropdown-alignment to hidden.

I tried to address #22, #50 and #58 by going back to the approach with fixed positioning in combination with a maximum height of the dropmenu, making it scrollable.
Also, the horizontal alignment is no longer dependent on the node form, but on two other aspects: the preferred reading direction (ltr or rtl) and the available space to the left or the right, just like we do with the vertical position.

I got the latest version in and it looks really good. Tested it on different pages with no content and with alot of contents and it all functional wise works. Great work!

Didn't had a look at the code, I leave that to a frontend developer :)

I've tested the MR!459.
It fixed the dropdown menu left aligned issue.

Attaching SS:

before:

after:

Hence moving it to RTBC...

+1 for RTBC. My issue from #40 has been resolved with the latest MR changes.

Same as previous comments, +1 for MR!459. It works well in all possible dropdown positions

+1 for MR!459 It works for me: 10.3.5 gin: 3.0@RC

@saschaeggi, fixed the pipeline phpcs issues. Please review the changes.

Thanks!

@tirupati_singh I pushed a change to remove the phpcs issues as they're not really issue but rather false positives. I'll look into why this MR behaves like this

saschaeggi → closed merge request !503

@tirupati_singh I was wrong, there were recently some phpcs changes for PHP 8.4 support, strangely enough this is the first MR which this shows up. See 📌 [PHP 8.4] Fix implicitly nullable type declarations Active

So I think we're good to go here 👏

Thanks everyone which was involved in fixing this bug 🙇

Automatically closed - issue fixed for 2 weeks with no activity.

jozl05 → changed the visibility of the branch 3242554-dropdown-menu-left-aligned to hidden.

jozl05 → changed the visibility of the branch 8.x-3.x to hidden.

jozl05 → changed the visibility of the branch 3242554-dropdown-menu-left-aligned to active.

jozl05 → changed the visibility of the branch 8.x-3.x to active.