Widget for multivalued file field overlap

@christosgeorgiadis Thanks for the merge request. However, I think you have not implemented the original patch correctly. The 'table' itself has the class '.table-file-multiple-widget' and its child td should be set to 'height: auto'.
Your solution works, but only because the table in question is a child of another table. I can imagine that there may be situations in which this is not the case.

I don't know much scss so I can't proceed any further to address your requirements. Someone more experienced should make a commit to the MR so that the patch is implemented properly.

Waiting for an RTBC here. Thanks!

I've tested the MR and while it does fix what it was trying to, I feel like we should address that the Alternative Text textbox, description and remove button can overflow outside if the browser window gets too small. Or should this be another issue of its own?

I´ve tested the MR !548 and it fixes my Problem!

Because of a nesting within a paragraph I was not able to click the button for further elements due to the bug.

Applying the patch makes the UI conform to my expectations, thank you very much. I would suggest the RTBC Status.

I think the drag button should be middle instead of top. I am working on it to fix.

Please review the changes.

Before:

After:

Noticed a couple of issues:

1. The layout breaks on mobile and iPad resolutions.
2. The "Remove" button is too close to the title and alt fields.
3. It would make more sense to display the image name below the image.

Fixed mobile and iPad resolutions. Also aligned remove button and image name.
Please review.

Before:

After

HI @mudasirweb, Thanks for your work however, I have a couple of doubts that I would like to clarify

1. Here below i attached ss for Single image field. So in case for multiple image field we should also maintain this design why we are putting
the image title at the bottom.

2. Could you please compile the SCSS file thoroughly? It seems to be causing a pipeline failure.

Fixed pipeline failure.

Hi @mudasirweb,

I noticed that the image title is still positioned at the bottom. As I mentioned in #21, it should maintain integrity with the single image field. If I am mistaken, could someone kindly verify it?

Moved image title to top in-order to maintain integrity with the single image field.

Thank you @mudasirweb and @sandip-poddar for taking care of further adjustments. However, I think it would be primarily important to get the original patch into a release, as the bug blocks the use of multivalued fields. We already have a confirmation for RTBC in #14. @saschaeggi could you please include this in a release?
Further adjustments like the centered drag handles and the title should imho be discussed in a separate issue.

Hi all, I've tried replicating the issue, and it reproduced. I've applied the provided MR as a patch, and it applied cleanly without any errors. After applying the patch, the multivalued image field overlap issue got resolved successfully, along with the mentioned issues in the comment #17 🐛 Widget for multivalued file field overlap Active . Now, the multivalued image fields occupying the required space and are not blocking the usage of multivalued fields, as mentioned by @piridium.

Thanks to @mudasirweb and @sandip-poddar for resolving further designing issues while using this theme. Initially, the drag handler is center-aligned for the theme for all fields/tables, so it would be better if consistency is maintained for the theme. As changes made for the handler are not affecting the other functionality while using the theme, hence moving the issue to RTBC. I've attached the screenshots of before and after fixes for reference.

Thanks!

Status set back to ‘needs review’. As already mentioned in #26, the patch in #3 solves the problem. The other adjustments introduced in the MR introduce new problems. Once again, I explicitly ask you to stick to the original problem of overlapping fields!

The application of MR548 leads to large layout errors with nested paragraphs. I have also attached screenshots showing the situation before and after the application of patch #3 and the MR458.

piridium → changed the visibility of the branch 3493765-multivalued-file-field-fix to hidden.

piridium → changed the visibility of the branch 3493765-multivalued-file-field to hidden.

I have created a new merge request that addresses the problem much more simply and makes better use of the existing CSS properties. Please review and test.

Hi all I attempted to replicate the issue, and it still occurred even after applying #3. I then applied the provided PR, and it was applied cleanly without any errors. After applying the PR, the multivalued image field overlap issue was successfully resolved, along with the issues mentioned in comment #17. The multivalued image fields no longer interfere with the use of multivalued fields.

Result #3 Patch
https://www.drupal.org/files/issues/2025-04-15/%233-patch.png →

Result after PR 3493765-widget-for-multivalued
https://www.drupal.org/files/issues/2025-04-15/Issue-fork-3493765-widget... →

Can someone please take a look.

@mudasirweb: Please also test MR608. It contains more than patch #3 and also solves the problem with the drag handle and the overflow.

In MR548, for example, @sandip corrected the drag handle with transformY(-50%). That can't be right. We have a display: flex here and the correct way would be imho align-self: center.

Hi @piridium, I tested MR608 and I’m still seeing the Remove button overflowing the border, and the image along with the drag handle are misaligned.

It looks like the issue stems from some internal gaps and margins within the image widget itself. I don’t believe align-self: center will resolve this.

That said, it no longer interferes with the use of multivalued fields, so I think MR568 is a good solution for now.

Screenshot after applying MR608
https://www.drupal.org/files/issues/2025-04-15/MR608.png →

Screenshot after applying #3
https://www.drupal.org/files/issues/2025-04-15/%233-patch.png →

Screenshot after Applying MR568
https://www.drupal.org/files/issues/2025-04-15/MR-568.png →

Thanks for the patch from gin-3493765 ‘MR !608’ this works perfectly for me!
Thank you very much!

Hi @mudasirweb, the overlapping issue is resolved by the MR 608 and align-self: center is used here to center the drag button that is totally correct. Now you are coming with the issue of responsive that is okay but the previous MR 548 fixes the responsive issue but it brings more issues that @piridium mentions in the MR with a image. I think we can go with the MR 608 it is fine. If we want to fix the responsive issue i observed width: 1px is applied to the td.file-operations-cell. This causes the input tag inside it overflow. Now this css is coming from claro. If somehow we remove this width: 1px then our job is done. See the image i have attached then it will be clear.

But in my point of view the main motive of this issue was to resolve the overlapping issue See this image → and that gets fixed by the MR 608.

cc: @piridium

This is the issue that i was talking about see the attached image.

Thanks @sandip, I totally share your view that we should open a separate issue for the problematic Claro styles.
Do I understand you correctly that you also agree we should set the status to RTBC?

Yes, I think we can put it on RTBC.

piridium → changed the visibility of the branch 3493765-widget-for-multivalued to hidden.

Yes @piridium, it is RTBC but we need to compile the SCSS properly.
Use npm install and then npm run build. If someone want fix it they can follow this step. Otherwise I am not available right now but will do it tomorrow.

Fixed the pipeline now the MR is good to go.

Thank you for your help! However, I have just noticed that I made a small mistake with the selector in the scss source. This has now been corrected and the MR is REALLY good to go. :-)

Hi @sandip, I understand your point — we're addressing one issue here and creating a separate ticket for the responsive issue. However, the goal isn’t just to get the MR merged, but to find the right solution.

If we look at MR568, it actually resolves both issues, and I genuinely wonder why we can't consider merging it. I've attached a screenshot after applying MR568 for reference:

https://www.drupal.org/files/issues/2025-04-15/MR-568.png →

I believe the community should take a moment to review both MRs and make a decision that best addresses the problem comprehensively.

@mudasirweb I’m assuming the reference to MR548 was intended, as that seems to fit the context. When looking at MR548, it appears that the ‘Remove’ button would be better placed in the ‘Operations’ column to maintain consistency. Also, I’m not entirely convinced by the use of translateY(-50%); I still believe that align-self: center would be a cleaner and more appropriate approach.

Also this line is not making any required changes in MR548. It is not needed.

.form-managed-file.has-value.is-multiple {
        display: flex;
        gap: 1rem;
        .form-managed-file__meta {
          align-items: center;
        }
      }

Hi @piridium, @mudasirweb
I think the best solution for this issue has landed on this issue https://www.drupal.org/project/gin/issues/3522015 🐛 Paragraph Active . Also the remove button is properly aligned with the operation button.

table.table-file-multiple-widget tbody td {
  height: auto;
  padding: var(--gin-spacing-density-m) var(--gin-spacing-m);
}

We do not need to apply this above for fixing the overflow issue. Please see this issue and share your perspective.

Here is the image after the fix: https://www.drupal.org/files/issues/2025-05-02/Screenshot%20from%202025-05-02%2011-26-20.png →

@sandip: Thanks for finding this related issue! That actually solves the problem on a higher level and leads to a better outcome.

But the drag handles aren’t centered here either. :-) That’s totally fine for now though — this can easily be addressed separately.

I’m closing this issue as a duplicate. If anyone disagrees, feel free to reopen.