Long custom block name forces 'Place block' button out of place

Thanks for reporting @Kumar Ashutosh and for providing the screenshot. I've just updated the title and issue summary a bit for clarity.

Also confirming it does not occur in Claro, only Seven.

Please review the patch.

Patch is working fine now the buttons are aligned for reference sharing screenshot ......
Thanks

Verified and tested patch #5 on drupal 9.3.x dev version and Seven 9.3.0 Dev version.
Patch applied successfully and looks good to me.

Testing Steps:

1. Log in as administrator and apply Seven theme
2. Create a custom block with a long name
3. Go to the block layout page and click 'Place block'
4. Observe the buttons are out of alignment
5. Now apply the patch and clear the cache
6. Again Go to the block layout page and click 'Place block'
7. Verify buttons should display properly aligned if the Block name is very long.

Expected Results:
The "Place block" buttons should be aligned properly if the Custom block name is very long.

Actual Results:
The "Place block" buttons are aligned properly if the Custom block name is very long.

Looks good to me. Moving this ticket to RTBC.

+++ b/core/themes/seven/css/components/tables.css
@@ -160,3 +160,7 @@ td > .form-item > .form-text,
+}

Although this fixes the issue as reported in a controlled test enviroment, it's a solution that introduces other problems.

This is limiting the length of every table cell within the table. Users with larger displays won't be able to take advantage of the additional viewport space. Longer titles/categories will be unnecessarily wrapped.

This is better addressed by targeting either the button itself, or determining why the table does not calculate button width when determining cell width.

Something like this would probably take care of it:

.js td .dropbutton-single .dropbutton-widget {
    position: static;
}

This is because the issue is probably due to it being a single-item dropbutton, and the widest (overflowing) part of the button is absolutely positioned and as a result not factored into the table cell width calculation. Since there's only one item in the button, the absolute positioning isn't necessary and making it static should allow the table to compute widths properly.

I agree with bnjmnm

I've created a patch for this

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

Testing Steps:
# Goto: Appearance -> Apply Seven Theme
# Create a custom block with a long name
# Go to the block layout page and click on 'Place block'
# Observe the (Place block) buttons are out of alignment

Expected Results:
# The "Place block" buttons should be aligned properly if the Custom block name is very long.

Actual Results:
# Currently "Place block" buttons alignment is broken.

Please refer attached screenshots for the same.
Looks good to me.
Can be a move to RTBC.

--- a/core/themes/seven/css/components/tables.css
+++ b/core/themes/seven/css/components/tables.css

This fix works, but should be applied to dropbutton-related css, not table-related css

The problem is caused by the following style in core/misc/dropbutton/dropbutton.css (without this rule, it defaults to the position: static; that fixes the issue

.js td .dropbutton-widget {
  position: absolute;
}

Which suggests it's potentially a problem in every theme, not just Seven where it happened to surface for the OP.

The position: absolute is necessary for multiple item dropbuttons, but causes the reported problem on single-item dropbuttons (and doesn't appear to provide any benefits). The ideal solution may be adjusting this rule to target only muti-item dropbuttons, or it may be adding a new style for single item ones.

What is there definitely works, but lets put it in the place where it'll work best for us!

Created a new patch and tested it as per comments from @bnjmnm. Attached screenshot with the new patch.

#13 Patch is working fine and shared the screenshot for the reference.

Just re-rolled the patch.

Before Patch:

After Patch:

#17 Patch is working fine and shared the screenshot for the reference.

After Patch

1. +++ b/core/misc/dropbutton/dropbutton.css
   @@ -37,6 +37,9 @@
   +}
   

   Inherit is risky because it literally inherits from its parent element, so the value can differ depending on what the parent positition is set to.

2. The overall approach in #20 is new. If this was a reroll, setting it to RTBC might be appropriate, but in this case it is self-RTBCing which isn't permitted. The RTBC must come from a reviewer who did not work on the implementation.
3. In general I notice most of these patches are adding new styles specifically for dropbutton-single, but it may be worth looking into just modifying the style causing the problem to only target .dropbutton-multiple
   This causes the issue in single buttons

   .js td .dropbutton-widget {
     position: absolute;
   }

   so perhaps this would take care of it? (this would need manual confirmation)

   .js td .dropbutton-multiple .dropbutton-widget {
     position: absolute;
   }

Thanks @bnjmnm that seems to be the right approach to me as well. I have added a patch based on your solution direction

Verified and tested patch #23 on 9.5.x-dev. Patch applied successfully.

Test Steps:
1. Goto Appearance -> Apply Seven Theme
2. Create a custom block with a long name
3. Go to the block layout page and click on 'Place block'
4. Verify the 'Place block' button is not out of alignment

Test Result: The "Place block" buttons is aligned as expected when the Custom block name is very long.
Attached screenshot for reference. RTBC +1

Tested the patch (3223061-23.patch) with version 9.5.x-dev. working fine looks good for RTBC.
screenshot attached for references : place-block-button-before-patch.png , place-block-button-after-patch.png

Thanks, everyone! Marking RTBC based on:

1. Patch applies cleanly.
2. Tests pass.
3. Title and issue summary are clear.
4. Change is simple and addresses the issue from the issue summary.
5. Not expected that tests are needed.
6. Issue metadata looks okay.
7. Manually tested and patch works as expected per above.

Compliments to @Kristen Pol for clearly stating what was done to support this issue being RTBC.

I am removing credit for duplicate screenshots made on the same patch.

Back to RTBC as per comment #27.

The thing happened! Applied to 10.1.x then cherry picked to 10.0.x and 9.5.x.

Also removed credit for rerolls where a reroll was not needed (basically uploading the same patch).

In case anybody else out there is now seeing funky looking placement of their paragraphs buttons (as in below screenshot, for example) due to the change from this issue, I've opened #3331203: Core 9.5.0 causing broken-looking styling (Legacy widget, with Seven) in paragraphs (though I didn't rule out that a more appropriate fix might be a change here, I haven't read through all the above, and assume a change in paragraphs is path-of-far-less-resistance anyway).