Bug 37024 - Scrolling "glitch" for some tables with sticky headers (that use DataTables)
Summary: Scrolling "glitch" for some tables with sticky headers (that use DataTables)
Status: ASSIGNED
Alias: None
Product: Koha
Classification: Unclassified
Component: Templates (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: Jonathan Druart
QA Contact: David Cook
URL:
Keywords:
Depends on: 40816
Blocks:
  Show dependency treegraph
 
Reported: 2024-06-04 13:13 UTC by Laura Escamilla
Modified: 2026-02-17 02:06 UTC (History)
29 users (show)

See Also:
GIT URL:
Initiative type: ---
Sponsorship status: ---
Comma delimited list of Sponsors:
Crowdfunding goal: 0
Patch complexity: Trivial patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
This fixes scrolling on some staff interface pages that have "sticky" headers for tables (for some browsers). For example, when scrolling down the circulation and fine rules page using a Chromium-based browser, the main table with the sticky header is initially difficult to scroll past and "jumps/flickers" a little before letting you scroll down the rest of the page.
Version(s) released in:
Circulation function:


Attachments
Bug 37024: Fix dataTable scroll glitch (930 bytes, patch)
2025-11-05 20:25 UTC, Lucas Gass (lukeg)
Details | Diff | Splinter Review
Bug 37024: Fix dataTable scroll glitch (977 bytes, patch)
2025-11-05 21:41 UTC, David Nind
Details | Diff | Splinter Review
Video of scrolling and jumping behavour - Chromium browser (6.94 MB, video/webm)
2026-01-06 18:16 UTC, David Nind
Details
Bug 37024: Fix dataTable scroll glitch (1.01 KB, patch)
2026-01-08 04:45 UTC, David Cook
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Laura Escamilla 2024-06-04 13:13:01 UTC
Similar to bug 36291, the holdings table is also glitching during scrolling. I'm seeing the following message in the console log:

"This site appears to use a scroll-linked positioning effect. This may not work well with asynchronous panning; see https://firefox-source-docs.mozilla.org/performance/scroll-linked_effects.html for further details and to join the discussion on related tools and features!"
Comment 1 Owen Leonard 2024-06-04 18:38:20 UTC
That warning will show up on any page that uses HCSticky as far as I know, and doesn't necessarily indicate an actual problem with the page.
Comment 2 Benjamin Daeuber 2025-07-09 21:40:33 UTC
I think this is still occurring in 24.11, even after the DataTables update. It may a separate issue, but staff have reported it here on long holdings tables.
Comment 3 Jason Robb 2025-07-17 18:13:59 UTC
I've gotten lots of reports of glitchy scrolling recently, possibly coinciding with 24.11.05.

It only happens in Chrome (my current Version 138.0.7204.158).

It seems to happen any time a table header wants to stick as you're scrolling down the page.

I was able to recreate it on Main in ktd by adding some holds then running the holds queue (10 rows seemed to be a sweet spot that really fired it up).

When you try to scroll slowly, it jerks the page back up. If you scroll quickly it can sometimes get over the bump.
Comment 4 Cindy Murdock Ames 2025-07-21 19:52:57 UTC
Not sure if this is helpful or even the same issue, but we've been experiencing this lately on 24.11 on our staff computers in Chrome (although I've been unable to replicate it myself).  Apparently it's been happening for a while so I'm not sure if a recent Chrome update has triggered or worsened it.  Anyway, a colleague found while checking things out in Chrome's developer tools that if you disable this (under Styles) the problem disappeared:

:root {
font-size: var(--bs-root-font-size);
}

That line is from /usr/share/koha/intranet/htdocs/intranet-tmpl/prog/css/staff-global.css


I have no idea how to disable that permaenently or if doing so is the correct thing to do or entirely reckless, but I'm putting it here in case someone in the know finds that this is the correct rabbithole to go down.  ;)
Comment 5 rpalermo 2025-07-22 15:10:12 UTC
I'm noticing the same behavior when scrolling on items, checkouts and also holds using the Edge browser. It also seems that the mouse needs to be positioned within the table to experience this issue. When moving the mouse off the table to the left, I don't see the same behavior.
Comment 6 carthur@slolibrary.org 2025-07-23 18:02:42 UTC
+1
Comment 7 Rebecca Coert 2025-07-23 18:03:07 UTC
+1
Comment 8 Lucas Gass (lukeg) 2025-07-23 20:23:28 UTC
I've tried my hardest to recreate this issue and cannot. I've tried k-t-d and production sites that are reporting the problem. I have tried Ubunutu and Windows. I have tried Chrome and FF. I can't recreate this.
Comment 9 Andrew Fuerste-Henry 2025-07-24 12:31:16 UTC
I can recreate on a fresh up-to-date KTD in Chrome version 138.0.7204.169 but not in Firefox version 141.0.
Comment 10 Cindy Murdock Ames 2025-07-24 15:23:02 UTC
An addendum: I was finally able to replicate it myself on my in-library work computer, which has more similar specs to our other staff computers.  This one has an Intel CoffeeLake-S GT2 UHD Graphics 630 graphics card, using the i915 driver, as do probably most of our other staff computers.  The one in my home office, where I couldn't replicate it, I think has an Nvidia Quadro 4000.

My colleague couldn't replicate it on his laptop on Chrome 138.0.7204.157, but he updated to 138.0.7204.168 and it started happening.

If I scroll slowly with the mouse scroll button it jumps all over the place, but if I scroll faster it gets past it.  If I use the page up/page down buttons on the keyboard it doesn't do it at all.

I'm wondering if it's an unfortunate combination of video hardware &/or driver plus the latest version of Chrome where it's most likely to happen.

Also the workaround someone mentioned in Edge where it wouldn't do it if you scrolled off to the left of the table doesn't work on Chrome.
Comment 11 Lucas Gass (lukeg) 2025-07-25 22:09:58 UTC
-This only seems to be reported in Chrome.
-An on scroll event is being triggered and reseting the `.dtfh-floatingparent` element to `top: 0`, which creates the flicker. 
 
It seems like we can mostly work around the issue by adding the following CSS:

.dataTable thead {
    position: sticky !important;
    top: 0 !important;
}


My question, is there anything fixedHeader is doing that cannot be done with CSS position sticky which now has wide browser support?
Comment 12 Jonathan Druart 2025-07-28 13:16:46 UTC
It would be worth trying with a newest version of DataTables.
Comment 13 Emily Lamancusa (emlam) 2025-07-28 21:02:32 UTC
I reproduce this on main and 24.11.02 in Chrome (I'm also on version 138.0.7204.158), and I confirm that Lucas's CSS snippet fixes it for me. (Thanks, Lucas!)
Comment 14 David Roberts 2025-07-28 21:33:05 UTC
Some of our customers have reported this in Edge too. The problem happens where the 'banner' reaches the top of the screen and Koha is reluctant to let the scrolling continue. There are a few seconds of juddering before the remainder of the long page flows under the banner that has reached the top of the page. There is often a difference in behaviour between using the mouse wheel, and the arrows at the top and bottom of the scroll bar in the browser.
Comment 15 Brendan Lawlor 2025-07-29 15:27:34 UTC
Our libraries just reported this in 24.11.06

Thanks for the css fix Lucas!
Comment 16 Katie Bliss 2025-07-29 20:15:52 UTC
I've seen this in Edge as well, though I went to go test again and can't actually reproduce it anymore. So perhaps no longer an issue in that browser?
Comment 17 Martin Renvoize (ashimema) 2025-08-27 20:46:03 UTC
Any more thoughts on this?  We've added the CSS fix from Lucas to our xCSS preferences for a number of our sites now reporting this.. but it would be good to have a core fix
Comment 18 Jonathan Druart 2025-09-02 07:45:56 UTC
(In reply to Martin Renvoize (ashimema) from comment #17)
> Any more thoughts on this?

First thing should be to confirm it's not fixed upstream.
Comment 19 Andrew Fuerste-Henry 2025-11-05 20:14:16 UTC
(In reply to Jonathan Druart from comment #18)
> (In reply to Martin Renvoize (ashimema) from comment #17)
> > Any more thoughts on this?
> 
> First thing should be to confirm it's not fixed upstream.

I can confirm this still exists in main. I'm most often seeing it in the circ rules (/cgi-bin/koha/admin/smart-rules.pl).
Comment 20 Andrew Fuerste-Henry 2025-11-05 20:18:18 UTC
(In reply to Andrew Fuerste-Henry from comment #19)
> I can confirm this still exists in main. I'm most often seeing it in the
> circ rules (/cgi-bin/koha/admin/smart-rules.pl).

In Chrome Version 141.0.7390.123 on a mac.
Comment 21 Lucas Gass (lukeg) 2025-11-05 20:25:10 UTC
Created attachment 189138 [details] [review]
Bug 37024: Fix dataTable scroll glitch

To test:
1. Observe the glitchy scroll behavior describe in this bug report.
2. Apply patch, yarn build
3. The scroll glitch should be gone
Comment 22 David Nind 2025-11-05 21:41:28 UTC
Created attachment 189140 [details] [review]
Bug 37024: Fix dataTable scroll glitch

To test:
1. Observe the glitchy scroll behavior describe in this bug report.
2. Apply patch, yarn build
3. The scroll glitch should be gone

Signed-off-by: David Nind <david@davidnind.com>
Comment 23 David Nind 2025-11-05 22:20:44 UTC
Testing notes (using KTD):

1. Tested on an Ubuntu 22.04 desktop, using Chromium, Firefox Developer Edition, and Google Chrome (latest versions),

2. Tested the circulation and fine rules page (Koha administration > Patrons and circulation > Circulation and fine rules).

3. Before the patch:
   - Chromium: jumps/flickers
   - Google Chrome: jumps/flickers
   - Firefox Developer Edition: no issues, scrolls as expected

4. After the patch:
   - Chromium: now scrolls as expected
   - Google Chrome: now scrolls as expected
   - Firefox Developer Edition: no change, scrolls as expected
Comment 24 Jonathan Druart 2025-11-06 07:52:59 UTC
(In reply to Andrew Fuerste-Henry from comment #19)
> (In reply to Jonathan Druart from comment #18)
> > (In reply to Martin Renvoize (ashimema) from comment #17)
> > > Any more thoughts on this?
> > 
> > First thing should be to confirm it's not fixed upstream.
> 
> I can confirm this still exists in main. I'm most often seeing it in the
> circ rules (/cgi-bin/koha/admin/smart-rules.pl).

by upstream I meant in newer DataTable version.
Can you try bug 40816 maybe?
Comment 25 David Nind 2025-11-06 17:36:22 UTC
(In reply to Jonathan Druart from comment #24)
> (In reply to Andrew Fuerste-Henry from comment #19)
> > (In reply to Jonathan Druart from comment #18)
> > > (In reply to Martin Renvoize (ashimema) from comment #17)
> > > > Any more thoughts on this?
> > > 
> > > First thing should be to confirm it's not fixed upstream.
> > 
> > I can confirm this still exists in main. I'm most often seeing it in the
> > circ rules (/cgi-bin/koha/admin/smart-rules.pl).
> 
> by upstream I meant in newer DataTable version.
> Can you try bug 40816 maybe?

I tried bug 40816 (apply patch, yarn build, restart_all) and the issue still exists.
Comment 26 Marcel de Rooy 2025-11-07 08:56:42 UTC
With this patch and yarn build, I still saw some glitchy behavior when scrolling down slowly from the start of the table with 10 longer rows on the admin/branches page.
Comment 27 Marcel de Rooy 2025-11-07 08:57:28 UTC
(In reply to Marcel de Rooy from comment #26)
> With this patch and yarn build, I still saw some glitchy behavior when
> scrolling down slowly from the start of the table with 10 longer rows on the
> admin/branches page.

In Chrome Version 142.0.7444.60
Comment 28 Marcel de Rooy 2025-11-07 09:06:08 UTC
Probably we should adjust the title of this report. Since it is a more generic thing.
Comment 29 Marcel de Rooy 2025-11-17 10:19:53 UTC
Moving to In discussion. This needs more testing or further changes.
Comment 30 David Cook 2025-12-17 01:22:48 UTC
(In reply to Lucas Gass (lukeg) from comment #11)
> -This only seems to be reported in Chrome.
> -An on scroll event is being triggered and reseting the
> `.dtfh-floatingparent` element to `top: 0`, which creates the flicker. 
>  
> It seems like we can mostly work around the issue by adding the following
> CSS:
> 
> .dataTable thead {
>     position: sticky !important;
>     top: 0 !important;
> }
> 
> 
> My question, is there anything fixedHeader is doing that cannot be done with
> CSS position sticky which now has wide browser support?

I've tried Lucas's CSS via IntranetUserCSS and while it might not be perfect, it certainly fixes the problem for us.
Comment 31 David Cook 2026-01-05 01:47:17 UTC
I was sad to see Lucas reset Assignee, so I took another look at this, and the patch works well for me even with tables of 12-15 entries. 

I did have to open my dev tools and force a refresh of the staff-global.css so that it didn't use a cached version. With the version that includes the following CSS, it works well:

table.dataTable thead {
    position: sticky;
    top: 0
}
Comment 32 Lucas Gass (lukeg) 2026-01-06 13:53:35 UTC
(In reply to Marcel de Rooy from comment #29)
> Moving to In discussion. This needs more testing or further changes.

I don't see that this was resolved or discussed, resetting to 'In discussion'/ Marcel, what further testing/changes are needed?
Comment 33 Marcel de Rooy 2026-01-06 13:55:41 UTC
(In reply to Lucas Gass (lukeg) from comment #32)
> (In reply to Marcel de Rooy from comment #29)
> > Moving to In discussion. This needs more testing or further changes.
> 
> I don't see that this was resolved or discussed, resetting to 'In
> discussion'/ Marcel, what further testing/changes are needed?

It didnt work for me.. So further tests could perhaps reveal more. But it didnt move much since then.
Comment 34 David Nind 2026-01-06 18:16:51 UTC
Created attachment 190946 [details]
Video of scrolling and jumping behavour - Chromium browser

Another table to see this on is Administration > Patrons and circulation > Patron categories.

Resize the length of your browser window so that you have to scroll to get to the bottom of the table.

Try to scroll to the bottom of the table:
- if you scroll slowly, you will never get to the bottom, and it keeps jumping and going back to the top of the table
- if you scroll very quickly, you will get to the bottom.

Only visible in some browsers - see my testing notes on comment #23

After applying the patch, a yarn build is required to regenerate the CSS.

Short video attached.
Comment 35 David Cook 2026-01-06 22:08:03 UTC
(In reply to Marcel de Rooy from comment #33)
> (In reply to Lucas Gass (lukeg) from comment #32)
> > (In reply to Marcel de Rooy from comment #29)
> > > Moving to In discussion. This needs more testing or further changes.
> > 
> > I don't see that this was resolved or discussed, resetting to 'In
> > discussion'/ Marcel, what further testing/changes are needed?
> 
> It didnt work for me.. So further tests could perhaps reveal more. But it
> didnt move much since then.

Have you confirmed that you're definitely using the patched version and not a cached version of the CSS? The patch has worked for Lucas, David Nind, and David Cook.

Note when I first tried it - it didn't work for me but that's because my browser was using a cached version of the CSS. I had to open my F12 dev tools, go to the network tab, ensure "Disable cache" was checked, and then hold shift and do a refresh of the page. It was only after those steps that I was able to load the updated CSS and get the fix working.
Comment 36 Lucas Gass (lukeg) 2026-01-07 21:30:57 UTC
(In reply to David Cook from comment #35)
> (In reply to Marcel de Rooy from comment #33)
> > (In reply to Lucas Gass (lukeg) from comment #32)
> > > (In reply to Marcel de Rooy from comment #29)
> > > > Moving to In discussion. This needs more testing or further changes.
> > > 
> > > I don't see that this was resolved or discussed, resetting to 'In
> > > discussion'/ Marcel, what further testing/changes are needed?
> > 
> > It didnt work for me.. So further tests could perhaps reveal more. But it
> > didnt move much since then.
> 
> Have you confirmed that you're definitely using the patched version and not
> a cached version of the CSS? The patch has worked for Lucas, David Nind, and
> David Cook.
> 
> Note when I first tried it - it didn't work for me but that's because my
> browser was using a cached version of the CSS. I had to open my F12 dev
> tools, go to the network tab, ensure "Disable cache" was checked, and then
> hold shift and do a refresh of the page. It was only after those steps that
> I was able to load the updated CSS and get the fix working.

I think maybe we can go with this as is. It is certainly fixing the problem for many. Why it persists for Marcel, I don't know. We've added similar CSS to many sites via IntranetUserCSS ( mentioned in comment #11 ) and no one has complained about adverse side effects. 

I will mark this back to 'Signed off'. Maybe one of the David's can put a QA stamp here? :)
Comment 37 David Cook 2026-01-08 04:45:11 UTC
Created attachment 191019 [details] [review]
Bug 37024: Fix dataTable scroll glitch

To test:
1. Observe the glitchy scroll behavior describe in this bug report.
2. Apply patch, yarn build
3. The scroll glitch should be gone

Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Comment 38 Jonathan Druart 2026-01-08 08:44:28 UTC Comment hidden (obsolete)
Comment 39 Jonathan Druart 2026-01-08 08:50:49 UTC
Sorry, late to the party.

The fix looked wrong to me, and I found some bugs:

1. With filters on the holdings table:
https://snipboard.io/Ka1UIL.jpg


Certainly coming from:
koha-tmpl/intranet-tmpl/prog/js/datatables.js
1146     table_dt.fixedHeader.adjust();

2. Also a problem on the item search where fixedHeader is disabled:
https://snipboard.io/TUmv7n.jpg

3. The headers of the pref tables are now sticky, they are not on main:
koha-tmpl/intranet-tmpl/prog/js/pages/preferences.js:    fixedHeader: false,
Comment 40 David Cook 2026-01-19 00:26:54 UTC
Seems like we're a bit stuck here?

Should we be fixing/changing each table one by one?
Comment 41 David Cook 2026-02-09 05:18:10 UTC
(In reply to David Cook from comment #40)
> Seems like we're a bit stuck here?
> 
> Should we be fixing/changing each table one by one?

Any more ideas from anyone?
Comment 42 Jonathan Druart 2026-02-09 10:29:16 UTC
(In reply to David Cook from comment #41)
> (In reply to David Cook from comment #40)
> > Seems like we're a bit stuck here?
> > 
> > Should we be fixing/changing each table one by one?
> 
> Any more ideas from anyone?

Maybe produce a minimal example and ask on DT's forum? https://datatables.net/forums/
Comment 43 David Cook 2026-02-09 22:13:08 UTC
(In reply to Jonathan Druart from comment #42)
> (In reply to David Cook from comment #41)
> > (In reply to David Cook from comment #40)
> > > Seems like we're a bit stuck here?
> > > 
> > > Should we be fixing/changing each table one by one?
> > 
> > Any more ideas from anyone?
> 
> Maybe produce a minimal example and ask on DT's forum?
> https://datatables.net/forums/

Yeah that's a good idea. I just looked at the Basic Initialisation example on FixedHeader and it works seamlessly. I wonder what we're doing that is making it not work...
Comment 44 David Cook 2026-02-09 22:17:01 UTC
(In reply to Jonathan Druart from comment #39)
> Certainly coming from:
> koha-tmpl/intranet-tmpl/prog/js/datatables.js
> 1146     table_dt.fixedHeader.adjust();

Hmm I commented that line out and it doesn't make a difference in /cgi-bin/koha/admin/smart-rules.pl

Interestingly... if I scroll to the far right FixedHeader works perfectly. If I scroll to the far left, FixedHeader has the scrolling bug...
Comment 45 David Cook 2026-02-09 22:25:58 UTC
(In reply to David Cook from comment #44)
> (In reply to Jonathan Druart from comment #39)
> > Certainly coming from:
> > koha-tmpl/intranet-tmpl/prog/js/datatables.js
> > 1146     table_dt.fixedHeader.adjust();
> 
> Hmm I commented that line out and it doesn't make a difference in
> /cgi-bin/koha/admin/smart-rules.pl
> 
> Interestingly... if I scroll to the far right FixedHeader works perfectly.
> If I scroll to the far left, FixedHeader has the scrolling bug...

If I delete the "colgroup" from the HTML, it doesn't have the scrolling bug...

But then the "Basic initialisation" example has a colgroup and it's fine...
Comment 46 David Cook 2026-02-09 23:04:23 UTC
(In reply to David Cook from comment #44)
> Interestingly... if I scroll to the far right FixedHeader works perfectly.
> If I scroll to the far left, FixedHeader has the scrolling bug...

Actually that's not quite right... there's a certain sweet spot with the scroll where the headings jump to the left... ugh
Comment 47 David Cook 2026-02-09 23:09:12 UTC
So I get the scrolling glitch on /cgi-bin/koha/admin/smart-rules.pl and /cgi-bin/koha/admin/itemtypes.pl but not /cgi-bin/koha/members/members-home.pl
Comment 48 David Cook 2026-02-09 23:26:16 UTC
(In reply to David Cook from comment #47)
> So I get the scrolling glitch on /cgi-bin/koha/admin/smart-rules.pl and
> /cgi-bin/koha/admin/itemtypes.pl but not
> /cgi-bin/koha/members/members-home.pl

I guess because fixedHeader is false on members-home.pl and the "fixed header" we do must be done via an alternate method. Although I see fh-fixedHeader used with div.searchheader... but maybe that's not doing anything there...
Comment 49 David Cook 2026-02-09 23:30:10 UTC
(In reply to David Cook from comment #48)
> I guess because fixedHeader is false on members-home.pl and the "fixed
> header" we do must be done via an alternate method. Although I see
> fh-fixedHeader used with div.searchheader... but maybe that's not doing
> anything there...

Yeah nah fh-fixedHeader does nothing there...

It's #memberresultst thead { 
  position: sticky;
  top: 40px
}

in staff-global.css...
Comment 50 David Cook 2026-02-09 23:54:28 UTC
(In reply to David Cook from comment #47)
> So I get the scrolling glitch on /cgi-bin/koha/admin/smart-rules.pl and
> /cgi-bin/koha/admin/itemtypes.pl but not
> /cgi-bin/koha/members/members-home.pl

I guess because fixedHeader is false on members-home.pl and the "fixed header" we do must be done via an alternate method. Although I see fh-fixedHeader used with div.searchheader... but maybe that's not doing anything there...


/cgi-bin/koha/admin/systempreferences.pl has the glitchy scroll. 

There's something about fixedHeader that seems weird...

It looks like folk have been interested in replacing fixedHeader with position:sticky  see issue 98 for DataTables/FixedHeader on github. (I'm refraining from posting too many links so I don't get autobanned...)
Comment 51 David Cook 2026-02-09 23:56:35 UTC
We're using FixedHeader 4.0.1 but that looks like it should contain these fixes:

"Fix: Bootstrap 5 was showing odd behaviour with scrolling - it was flickering the scroll position during the mode transistion."
"Fix: "Jittering" when the table starts to scroll (in certain cases)"
Comment 52 David Cook 2026-02-09 23:58:42 UTC
I commented on https://github.com/DataTables/FixedHeader/issues/105 titled "bootstrap 3 fixedheader scrolling down issue" which has a video which looks the same as ours I think...
Comment 53 David Cook 2026-02-10 00:15:59 UTC
I tried rebuilding our datatables.min.js and datatables.min.css using the latest and greatest via the DataTables builder, but the problem still happens.

It looks like a lot of attempts have been made at fixes over the past few years. I do wonder if just not using fixedHeader would be a better way to go...
Comment 54 David Cook 2026-02-10 22:53:02 UTC
(In reply to Jonathan Druart from comment #42)
> Maybe produce a minimal example and ask on DT's forum?
> https://datatables.net/forums/

Thanks for inspiring me to go to the source, Jonathan!

The author Allan wrote a fix for it last night: https://github.com/DataTables/FixedHeader/commit/3defb25dbfe1533dded755f614e2c5ecfcd0226c

He was really responsive on the Github issue. 

I've asked when he thinks it will be added in a tagged release.

Of course, since we include FixedHeader in the datatables.min.js bundle, we'd have to replace the whole bundle. 

It would be good to get this fixed though.
Comment 55 David Cook 2026-02-11 22:21:04 UTC
Allan the DataTables author says he should have a tagged release ready this week. So that's good!
Comment 56 Katrin Fischer 2026-02-12 07:58:17 UTC
(In reply to David Cook from comment #55)
> Allan the DataTables author says he should have a tagged release ready this
> week. So that's good!

Very cool!
Comment 57 Jonathan Druart 2026-02-12 08:12:32 UTC
Would be great to push bug 40816 then continue with the latest version that is going to be released?
Comment 58 David Cook 2026-02-12 22:20:39 UTC
(In reply to Jonathan Druart from comment #57)
> Would be great to push bug 40816 then continue with the latest version that
> is going to be released?

Good question. I doubt bug 40816 would be backported, but I suppose backports would have to involve a careful bundle regeneration anyway... so for main yeah doing bug 40816 with the latest FixedHeader plugin would probably work?
Comment 59 David Cook 2026-02-16 00:23:25 UTC
(In reply to David Cook from comment #58)
> (In reply to Jonathan Druart from comment #57)
> > Would be great to push bug 40816 then continue with the latest version that
> > is going to be released?
> 
> Good question. I doubt bug 40816 would be backported, but I suppose
> backports would have to involve a careful bundle regeneration anyway... so
> for main yeah doing bug 40816 with the latest FixedHeader plugin would
> probably work?

FixedHeader 4.0.6 is now released and I've confirmed the correct version is included in the DataTables bundle builder. 

And looking at the builder again... I guess we do have to update the entire bundle when we want to upgrade any particular subcomponent...

So let's get bug 40816 pushed... and then do this bug report with the latest and greatest which should be fairly close to what's in 40816 anyway...
Comment 60 Jonathan Druart 2026-02-16 08:53:08 UTC
(In reply to David Cook from comment #59)
> And looking at the builder again... I guess we do have to update the entire
> bundle when we want to upgrade any particular subcomponent...

I can work on that as soon as bug 40816 is pushed.
Comment 61 David Cook 2026-02-17 02:06:28 UTC
(In reply to Jonathan Druart from comment #60)
> (In reply to David Cook from comment #59)
> > And looking at the builder again... I guess we do have to update the entire
> > bundle when we want to upgrade any particular subcomponent...
> 
> I can work on that as soon as bug 40816 is pushed.

Sounds good. Passed QA on bug 40816. 

I'll obsolete the patch here in the meantime.