Table header overflow issue for multiple user role on permissions page.

This seems related?

See also https://www.drupal.org/project/gin/issues/3338209#comment-14945131 🐛 Sticky header triggered to early Closed: outdated

I have fixed this issue by adding overflow-x auto to table parent div wrapper. Please check the patch. Also attached video.

I have tested #11,
getting warnings "warning: 2 lines add whitespace errors."

Issue is fixed after applying patch

before

after

I've opened MR !244 for a more elegant solution.
Please review

Cheers!

This doesn't quite fix it yet. It makes the table horizontally scrollable, but the table header isn't right yet. It creates a duplicate sticky header which still overflows the screen, without removing the old header.

@DieterHolvoet I'm moving this back to needs review as the MR fixes the described issue here. The permissions page does not have a sticky header btw. Are you using maybe a module which alters this page? Let's keep them separate. Free to open an issue for that module in combination with the permission page.

I can reproduce it on another project with this patch applied as well. No modules are altering the permissions page. No other Gin patches except for this one, applied to dev-3.x. The duplicate header only happens if the permissions table has horizontal overflow, if not it works fine (but it's sticky either way).

Something else: $variables['attributes']['id'] doesn't seem to always be set. On admin/config/development/mail_safety using the Mail Safety module → it's not set.

You should probably also remove the var_dump().

Fixed on scroll header sticky. Please review.

LGTM, just needs a community review

The issues as described in #19 are still present.

@DieterHolvoet sorry for the issue hopping but can you test the MR in 🐛 Sticky header for non views tables Fixed ? Will this address your issue?

No, after applying that MR to a project no sticky header appears anymore on the permissions page. I also can't apply both that MR and the one here since they give conflicts.

@DieterHolvoet that is strange, the other MR enables sticky headers. Did you clear the cache? As it has a template change it most likely won't work without a CR.

Yes I did! I added a console.log to the JS to make sure the new one is picked up and it is, 'test' is logged exactly once.

The new .gin-table-scroll-wrapper element is also present.

@DieterHolvoet I pushed a fix, as there was an issue in Chrome and a bug in FF. Can you try it again? Thanks!

Now it works, except if the table header overflows the page horizontally. In that case the header appears sticky immediately and never disappears:

except if the table header overflows the page horizontally

Which this issue is actually for, so we're good to go on the other one I guess 😉

Also does this overflow issue happen in Claro, too?

On Claro the page overflows horizontally, but both the normal and sticky headers are in the correct position when scrolling horizontally:

Experiencing the same when there is overflow horizontally. Happy to test when something is ready!

Hi,
I applied patch #38, it makes the table horizontally scrollable and all roles are visible. But once we scroll vertically, sticky header gets attached to table which doesn't show all user roles. It also creates extra space on right side of the page.
Thanks

Unfortunately, I couldn't apply the patch on latest RC or the dev branch.
It might be due to this ticket that has been merged and also affect sticky tables: 🐛 Table sticky header appears when table not in viewport Fixed

I've created a simple patch that listens to the scroll position of the table wrapper and scrolls the sticky table headers over proportionally.

@francois-p-peloquin I have checked the #42, with gin as admin theme.

Steps to reproduce the issue:

1. After user logged in, go to People > Roles
2. Add multiple roles
3. Go to People > Permissions

the patch #42 applied successfully but there is an issue which need to be fixed this is same as clore.

So when using 10.2 we also got introduced to a new issue with the header, due to the change from 📌 Use position: sticky for views sticky table header Fixed , we now use position: sticky on the header instead of creating a separate table with the header inside of it.

This causes the header to not stick to the top anymore, this is due to the 'overflow: auto' we use on the "gin-table-scroll-wrapper" class.

Removing the overflow: auto resolves the issue of it not sticking to the top anymore, but obviously this makes the permissions go out of bounds of the wrapper that we are using, which creates another problem on its own.

Due to the change from 📌 Use position: sticky for views sticky table header Fixed we now have a 'position-sticky' class instead of the 'sticky-enabled' class, which also needs some rewriting I suspect.

I don't know if its better to put this into another issue or change up this issue a little bit to fix both of the issues that now revolve around the header.

Indeed I can confirm #45! Thanks for the quickfix!

TBH without the "overflow: auto;" it behaves 'more' correctly to me. The column labels are always positioned correctly then and the table header is sticky.

I also have the same issue on the webform list page "admin/structure/webform" where I have 3 different webforms, but in very particular browser height and depending on the page content, our first webform is inaccessible/hidden on scroll.
Removing the overflow: auto; also seems to solve the issue.

The patch is adding a scroll event listener. Would it be more performant to use intersection observer?

Eduardo Morales Alberti → made their first commit to this issue’s fork.

I've created a new branch with a complete new approach and for me it seems to work locally, but I'd love to gather some more feedback.

Can somebody please test the branch https://git.drupalcode.org/project/gin/-/merge_requests/404?

You can generate a patch to use against the latest dev with https://git.drupalcode.org/project/gin/-/merge_requests/404.diff

Thank you in advance!

Thanks @saschaeggi just a note for you and the others: There's a Tugboat link for the MR that can be used for manual testing this easily: "View live preview!"

Great to see progress here, thank you so much! :)

I've tested this on one of our sites, but I noticed that with a lot of roles, it creates loads of blank space next to the permissions wrapper div.
Adding the css: "table-layout: fixed;" kinda fixes this problem, however now everything gets cramped together which is also not wanted.

@Arantxio

it creates loads of blank space next to the permissions wrapper div

Can you share a screenshot?

kinda fixes this problem, however now everything gets cramped together which is also not wanted.

For this as well. Thank you.

I've setup some artificial roles in the linked Tugboat of the MR and can't reproduce the whitespace, see https://mr404-tvh4mpqiaqdfkkufdvfcc1xmmqdtjaxd.tugboatqa.com/admin/peopl... (admin/admin)

Here are some screenshots:

The cramped layout:

The whitespace:

I've even tried it on tugboat and here i can also see the whitespace, in this case black space because of the theme.

@Arantxio I was able to reproduce it in Chrome. I've pushed a fix.

Pushed another change to switch to use scrollsync to avoid some of the jerkyness when positioning an element with JS within overflow.

Testers wanted 👀

Tugboat is sadly broken (Failed) but the fix works great for me so far, thank you Sascha!

Tugboat preview is fixed, can be tested at:

1. https://mr404-tvh4mpqiaqdfkkufdvfcc1xmmqdtjaxd.tugboatqa.com/user
2. Login with admin/admin
3. https://mr404-tvh4mpqiaqdfkkufdvfcc1xmmqdtjaxd.tugboatqa.com/admin/peopl...

Hey @saschaeggi,

The table scrolls horizontally as expected both when in sticky mode and not in sticky mode. So that's all good.

However, I'm experiencing a horizontal scroll outside of the table too. I'll upload a screen recording showing what I mean. [gin-roles-horizontal-scroll.mp4]

Macbook 15", Chrome.

Not sure whether this is the best fix, but setting the position attribute of the table to be "relative", before it's then set to "sticky" appears to remove the unwanted horizontal scroll for me in Chrome. See screenshot attached.

@Hebl I pushed a fix for Chrome 👀

Thanks @saschaeggi, I've tested the update and fix is applied. :)

I can confirm that it also works properly on our site now.

I've applied MR404 mainly to address sticky headers on the permissions page (lots of related - closed - issues), but I actually see 2 sets of table headers with the patch applied. The upper header obscures the 'filter' box on permissions on page load, but is the header that remains sticky when I scroll down.

@robcarr I can't really reproduce this, can you provide steps how to reproduce this, Browser & which Drupal version you're using. Also does it happen only on a single instance (so potentially another module is interfering?)

Hi i've tested the patch. And i've found that there are still some things that can use adjustments. On viewport 959px and smaller it prints the sticky header twice, so it seems. Furthermore there seems to be an issue regarding the z-index with the Dropbuttons (operations) having a larger z-index than the sticky header causing overlap.

saschaeggi → closed merge request !244

@saschaeggi - it's a complex D10.2 site but the issue seems to be down to the margin-bottom value calculated in js > tableheader.js updateTableHeader function by the line:

tableHeader.style.marginBottom = `-${el.querySelector('thead').getBoundingClientRect().height + 1}px`;

In my instance the THEAD has a height of 54px, so the marginBottom value should be 55px, but the JS implements this as in inline style value -54px in the enclosing table. If this value is changed to 20px then the 2 table headers are visible, but the upper, sticky header is above the system 'Filter' input box and it's at least usable.

For the moment I'm just going to use some hacky CSS in sites/default/files/gin-custom.css to get around this. Will probably break something else...

.user-admin-permissions .gin--sticky-table-header{
  margin-bottom: 55px !important;
}

(Sorry about the !important value. I know)

saschaeggi → credited Murz → .

@robcarr how can I reproduce your scenario?

As using your overrides will certainly break it for the general implementation.

The https://www.drupal.org/project/gin/issues/3293369#comment-15438112 🐛 Table header overflow issue for multiple user role on permissions page. Fixed works for minimal item of roles.

@brian.flores@codeandtheory.com #47 is not a solution we can move forward with. Please test the branch instead 👀

MR404 has resolved a lot of the issues I was having on various Webform tables.

Let's get this in! 🎉

Thank you all so much for collaborating on this one! Good things take time! 😅👏🧡

Thank you very very much @saschaeggi, great work!
Looking forward to the next release :)

Sorry, but testing this on the latest 3.x-dev@dev, I see two header rows on the permissions table (one of which is sticky) and no means of scrolling horizontally to roles that overflow the right of the container.

I'm seeing the same. Two header rows but at least the sticky works!

Can you share some more information like for example which Drupal version you're using and can you share a screenshot please?

I'm using Drupal 10.2.6 and PHP 8.2.12. Gin 3.x-dev@dev.

Latest Gin, Drupal 10.2.6, PHP 8.2.18 - Not able to replicate the double row headers some folks are seeing. Tested with left and top toolbar.

@david.qdoscc I'm unable to reproduce this just yet. Did you clear the cache(s)? I would need steps to reproduce this and if there are any other community modules involved which potentially could interfere here.

I've found it! Module Filter → is to blame.

@david.qdoscc can you open an issue so we can track it there? TY!

Sure. Here it is: 🐛 Permissions table header is misaligned when using Gin Admin Theme Needs review

@david.qdoscc @selwynpolit

I moved the issue to the Module Filter project as the root cause is within that module -> https://www.drupal.org/project/module_filter/issues/3452725 🐛 Permissions table header is misaligned when using Gin Admin Theme Needs review

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