Table rows in a form that only contain checkboxes are not visible

There is nothing wrong with the module at all. This is caused by the latest Gin theme. I can confirm, that with Drupal 10.2 and Gin 3.0.0-rc8, the first row of the table, which contains all the important checkboxes without labels, has a height which is too small so that the content of that row is invisible.

Not sure which change in Gin actually caused this, but when changing the admin theme to Claro, the checkboxes show up as expected.

Moving this issue to the Gin issue queue. @saschaeggi, in the screenshot above there is a table row containing just checkboxes without labels, and they are invisible because of the row height not being calculated correctly. Not sure what exactly caused this change, but it's certainly Gin in Drupal 10.2 - I'm happy to help fixing this, but don't have a clue where to look there.

Is this a duplicate of #3409575: Checkboxes broken in Slick/Splide/Blazy maybe?

I'm pretty confident we haven't touched anything related which caused this issue however maybe we removed something upstream in Claro which we relayed on (CSS styles) which aren't present anymore.

So this might be the culprint of the issue.

Can you check if the MR in the other issue fixes this issue?

The patch from the other issue doesn't fix this issue. For some reason, I now can't even reproduce the fix by switching to Claro. Not sure what I did before to show the checkboxes with Claro, but not with Gin. I'll investigate further.

Think I found it: the .position-sticky thead selector in tableselect.css:134 defines this:

top: var(--drupal-displace-offset-top);

with --drupal-displace-offset-top set to 79px. That result in tbody being underneath the sticky header:

When disabling that top attribute, we get the correct result:

No sure what's the best path forward to get this addressed?

Note, this is a sticky table header because the table below can grow pretty large, and having the header stick around would be helpful. The markup for that table is coming from that render array:

    $form['danse']['events'] = [
      '#type' => 'table',
      '#sticky' => TRUE,
      '#header' => $header,
    ];

If I change sticky from TRUE to FALSE, all looks good too.

So, Claro may have introduced a regression for sticky table headers under certain circumstances?

@ Jürgen tableselect from where? Core? Claro? Our tableselect does not have this definition on L134.

So when we replace the displace variable with Gin's displace:

--gin-offset-y

When disabling that top attribute, we get the correct result:

Is the table header sticky at all in this scenario?

I believe a sticky table header will generally not work in a vertical tab setup as the overflow definition will break the ability for sticky to work properly (in Claro and therefore in Gin too) and I don't think this is fixable at all with the current Core integration of vertical tabs. But I might be wrong on this if you tell me it actually works 😅

If no, we should override top to either use 0 or auto to keep it at the top.

tableselect from where? Core? Claro?

This is in Claro. Sorry, my comment in #4 was probably a bit confusing, I wanted to clarify that it doesn't seem to be a Gin issue but caused by Claro and therefore being inherited by Gin too. I'm just not clear of where to follow up with that issue, so I left it here for the time being.

I believe a sticky table header will generally not work in a vertical tab setup ...

You're right! I've just checked on a smaller screen, and it doesn't even work at all.

So, I'm going to remove the sticky property in DANSE. That will resolve the original problem. Also, since sticky isn't supposed to be working in this context in the first place, we most likely don't want to follow-up with the underlying problem, I guess.

Moving the issue back to DANSE to that I can refer to it in the commit to fix this. @saschaeggi thanks a lot for looking into this and helping us to learn that sticky is out-of-scope in vertical tabs.

@lazzyvn This is now fixed in the latest 2.3.x-dev release. Can you please try that out in your environment to confirm that we really caught it? I'll then publish a patch release 2.3.1 when this is OK.

@Jürgen can you create a Core (Claro) issue that we reset the position for tables placed inside of vertical tabs? Thank you

@saschaeggi here you go: #3411301: Sticky table headers overlap first body row when table is inside vertical tabs