Problem/Motivation
The sticky table header is triggered whenever the header is out of the viewport, even if the header is below the bottom of the viewport. In other words, when the table is out of view (at the bottom of the page), the sticky header will show on top of the page, covering some necessary contents.


Steps to reproduce
Just go to any admin interface with a sticky table near the lower half of the page. View pages with a preview table on the bottom is a good choice. The sticky table header will show when the page is loaded. Start scrolling, and the sticky header will disappear when the actual table header comes into the viewport. Then when the table is scrolled up enough to hide the header, the sticky header will show again as expected.
Proposed resolution
The trigger is the IntersectionObserver in tableheader.js (themes/contrib/gin/js/overrides/tableheader.js)

the statement on line 16
if (!e.isIntersecting && e.rootBounds.top === stickyOffsetTop)
is checking rootBounds.top with the stickyOffsetTop. However, since the sticky table header is inside of the real table, and it's positioned absolutely on top of the page at the stickyOffsetTop location, the test e.rootBounds.top === stickyOffsetTop will always be TRUE.
Instead, it should be using e.intersectionRect.top === stickyOffsetTop so it's checking the top of the table position rather than its parent.
Original code
if (!e.isIntersecting && e.rootBounds.top === stickyOffsetTop) {
context.querySelector('.gin-table-scroll-wrapper').classList.add('--is-sticky');
} else {
context.querySelector('.gin-table-scroll-wrapper').classList.remove('--is-sticky');
}
New code
if (!e.isIntersecting && e.intersectionRect.top === stickyOffsetTop) {
context.querySelector('.gin-table-scroll-wrapper').classList.add('--is-sticky');
} else {
context.querySelector('.gin-table-scroll-wrapper').classList.remove('--is-sticky');
}
Remaining tasks
Someone please test this and see if I should generate a patch.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | Screenshot from 2023-09-11 12-14-38.png | 150.93 KB | shubham_jain |
| #6 | Screenshot from 2023-09-11 12-13-49.png | 65.15 KB | shubham_jain |
| #5 | 3386007-gin-sticky-header-fix.patch | 763 bytes | jmouse888 |
| Screenshot_2023-09-07_18-12-31.png | 111.75 KB | jmouse888 | |
| Screenshot_2023-09-07_18-16-09.png | 70.15 KB | jmouse888 |
Issue fork gin-3386007
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
shubham_jain commentedComment #3
jmouse888 commentedI'd like to clarify something. When using intersectionObserver, it's recommended to use
rootBounds. However, we face a problem with the sticky header <table> tag as it exists within the actual <table> tag and is positioned absolutely at thestickyOffsetTop. This causes therootBounds.topof the actual table to always be at thestickyOffsetTopposition when the table is outside of the bottom of the viewport, triggering the display.When using
intersectionRectfor the real table, only the visible area of the table is considered, which does not include the hidden sticky header <table>.Alternatively, instead of changing to
intersectionRect, we can move the sticky header <table> outside of the main <table> tag in HTML. I don't know if this is done by Gin or Claro. I believe most other themes do that, but the pros and cons of doing so is another debate for another day.Comment #4
jmouse888 commentedComment #5
jmouse888 commentedGenerated a patch to change the
rootBoundstointersectionRect. I don't know how to do a merge request or even be able to. Someone test this please. Make sure to clear the browser's cache as well as the Drupal cache.Comment #6
shubham_jain commentedHi everyone, I tried the patch in the comment #5 but it didn't resolve the issue. Attaching the screenshot for reference.
Comment #7
jmouse888 commented#6, Can you put a watch on "e" and see what value it has when the header is visible? Or when you scroll up and down? thx.
Comment #8
shubham_jain commentedSorry, it was my mistake that setup itself was having some issues. But with the fresh installation your solution worked.
Comment #10
saschaeggiThanks @jmouse888
Verified on 10.1.3 on a views edit page with a sticky table.