Sticky header triggered to early

Can confirm this is happening for me too. It seems to occur for browser/screen width between 976px to 1145px (inclusive).

Does this happen in a specific browser? As it doesn't seem to happen on my end.

The issue happens for me on all browsers I've tried. For example, Chrome on macOS Version 110.0.5481.77 (Official Build) (arm64)
And also Firefox on macOS Version 109.0.1 (64-bit) -- see attached screenshots for reference.

To reproduce this issue, I start with a maximised browser window and gradually reduce its size until the redundant sticky header appears.

Same for me, on linux Firefox 109 and Chrome 110.0

Happens in Brave too (Version 1.48.158 Chromium: 110.0.5481.77 (Official Build) (arm64)).

I had another look in Chrome, Safari, FF & Brave and don’t seem to be able to reproduce it. Maybe it only happens with specific modules enabled? Happy if somebody which actually is affected by the problem have a look at how we potentially can solve it.

Cheers

For us this seems to be caused by the fact the --is-sticky class is added by Drupal.ginTableHeader.
Sometimes the thead is not visible yet because the user has a lot of exposed filters and a small browser window. This will cause e.intersectionRatio < 1 to be true (since the thead is not visible) and triggers the sticky header.

I think the sticky header should only be triggered when window.scrollY > context.querySelector('.gin-table-scroll-wrapper').offsetTop, but not sure yet why e.intersectionRatio < 1 was added in the first place.

This seems to do the trick. The window.scrollY needs an extra offset for the admin toolbar. Added 80px for now, but I think there should probably be a better way to get that height.

Thanks @seanB but the patch doesn't work. It removes the sticky header completely as the class "--is-sticky" is never added

Here is another attempt. The observer sometimes just doesn't seem to fire. We could make the observer threshold lower, this seems to make it better for me. We could also simply remove e.intersectionRatio < 1. Could you check if this helps?

This one works better.

On loading the page everything's fine. No double header. Scrolling down the header stays fixed on top as wished.

When scrolling back up to the top there is again the double header.

Actually it probably works with a native drupal table. Ours is slightly modified as the exposed filters are collapsed by default. When open scrolling up is no problem anymore

I made some tests on my without my exposed filter customisation

Scrolling down everything works fine, sticky header appears when the table's header disappears from screen

Scrolling up again the sticky header remains even when the table's header reappears, provoking a double header until I scroll above the exposed filters

On a view without exposed filters scrolling up is no problem.

So looks like the views exposed filters aren't handled well.

The patch from #13 partially worked. It worked when scrolling down, but failed to remove the --is-sticky class when scrolling back up. Uploading a patch that worked for me. The key for me was updating the logic to check for e.intersectionRatio === 0 instead of e.intersectionRatio < 1.

I was able to get the sticky header hiding/showing correctly when the table overflows on the horizontal axis. The underlying reason for this issue is that the IntersectionObserver API examines both the x and y axes and when the table is too wide to fit within the viewport it, technically, intersects with the right edge of the viewport which causes the sticky header to display.

We can fix this by observing the first

Patch #18 works perfect for me with tables with a few rows, no problem any more with the exposed filters (even when customised)

However is the solution to deactivate the the sticky header with tables that overflow horizontally, the good approach?

Shouldn't there be a horizontal scroll as suggested on Table header overflow issue for multiple user role on permissions page. #7 🐛 Table header overflow issue for multiple user role on permissions page. Fixed ?

I agree that, ideally, when scrolling horizontally the sticky header should also scroll, but what makes this difficult to implement is that when the header becomes sticky it becomes detached from the table (hence the stickiness). The only way I can think to resolve that is with some custom Javascript that binds to the horizontal scrolling on the table wrapper and updates the scroll position or x position of the sticky header - something I currently do not have time to help with, but maybe the maintainer of Gin has some ideas?

Thanks, your fix already helps.

Lets see if a solution for the horizontal scrolling can be found. Unfortunately, my JS skills aren't up to the task.

Hi there

I encountered the same problem. I tested the latest dev version (dev-3.x, commit 9abb2b2) on a vanilla Drupal installation and randomly added columns to the content view:

We can see 2 problems:
1. The --is-sticky class is added although we haven’t scrolled down yet. This is caused by the intersection observer which always detects an intersection as soon as the view overflows the viewport horizontally.
2. The sticky header is not scrollable.

For the first problem, I might have come up with a – rather «creative» – solution: Instead of observing the table header – which always triggers an intersection when it’s wider than the viewport – we could add an absolutely positioned element to the table header and observe this element. Due to the absolute positioning, horizontal scrolling does not cause intersections and therefore the –is-sticky class is not toggled.

The second problem could be resolved by adding a scrollable wrapper around the sticky table and sync its scrolling with the views scrolling.

I did some changes (https://git.drupalcode.org/issue/gin-3323501/-/tree/3323501-table-sticky...) to implement those two suggestions. However I didn’t test them very thoroughly – they are more like proof of concept (and feel a bit hacky…).

What do you think – could that be a possible solution? Let me know if I can help you with this!

Closing as it will be fixed with 🐛 Sticky header for non views tables Fixed

Hey @saschaeggi,

This is still an issue in following case.

When the user has a lot of exposed filters and a small browser window, this will cause e.intersectionRatio < 1 to be true (since the thead is not visible) and triggers the sticky header.

OR

Zoom the window / Open inspector window and adjust screen height till half the table header is visible.

Closing this again as it has been addressed and verified with 🐛 Sticky header for non views tables Fixed .

Unfortunately the bug is still occuring in 8.x-3.0-rc4