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

Can you please test this against Alpha37 (or against latest dev) if this is still an issue?
As this should have been fixed already with #3224124: Dropbutton actions form element is styled incorrectly

Could you reproduce it with the latest Alpha37 or latest dev builds?
Thanks

I'm able to reproduce this with alpha37 and the latest dev build. It seems that this is caused when any secondary link in the dropbutton is longer than the primary link of the dropbutton.

When this is the case, the dropdown will expand to the left beyond the left hand side of the button. When the dropbutton is on the left edge of the window this can result in the secondary links becoming invisible.

I couldn't find any examples in Drupal core where there is a dropbutton on the left hand side of the screen... but reviewing #3224124: Dropbutton actions form element is styled incorrectly I remembered this was happening in the $form['actions'] area. So to reproduce you can copy the code snippet from that issue's steps to reproduce, and make one of the secondary link values extra long. I've attached a screenshot of this.

Interestingly I found a dropbutton (maybe?) in the views_ui ViewEditForm that automatically expands to full-width of the secondary links when the button is expanded. It isn't *perfect* but maybe this would be a solution to consider? Attaching screenshot of what I am talking about. Interestingly, this same form has a dropbutton that seems more "normal" and does not do the auto expand. I tried to find where this auto-expand is happening but didn't see it on my first pass.

Thanks @saschaeggi - that didn't fix it for me but I think it pointed me in the direction of how to fix this!! I'm not actually using the node module or the special Gin edit form so I think the distinction between .node-form and .layout-node-form is irrelevant to me... I'm afraid I can't test if that fixes anything...

but... it made me realize that similarly if we set left: 0 for dropbutton items that are within the .form-actions class, this issue should be fixed for any dropbuttons that are children of an actions element '#type' => 'actions' in a form.

The change in MR66 fixed the example provided in this issue: #3224124: Dropbutton actions form element is styled incorrectly And looking at the screenshot in #1 it appears that the dropbutton may be in an "actions" element too.

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?

@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;
}

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 #3456018: gin-table-scroll-wrapper hides drop down options if they expand beyond container, 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.

@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

In the code MR-459, can we use el.closest('form') instead of el.closest('.node-form')? It fixes the issue mentioned in #22 but I'm not sure if it is the correct solution.
.
I have created an MR with the said changes. Please check.

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.

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 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
• Redirect 1.9.0
• 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. Attaching screenshots for reference.

But it doesn't addresses the issue mentioned in #22

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

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 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

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

@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 #3427999: [PHP 8.4] Fix implicitly nullable type declarations

So I think we're good to go here 👏

Thanks everyone which was involved in fixing this bug 🙇