On testing bug 36130, I found that scrolling had some glitch (at least on my computer, Firefox on ARM64 macOS). I used the following command to fill the DB with several batches: ``` PERL5LIB=$PERL5LIB:./lib perl fake_data.pl --how-many 100 --entity ill for x in {1..21}; do echo "INSERT INTO illbatches (name, backend, library_id, status_code, patron_id) VALUES ('$x', 'FreeForm', 'CPL', 'NEW', 52);"; done | koha-mysql kohadev ```
Hi Tomas, thanks for this. I'm unable to look at it properly but will as soon as I can. It seems you're running 2 different commands, one for requests data and one for batches data. This shouldn't cause any issue, but it's not something I've done before.
(In reply to Pedro Amorim from comment #1) > Hi Tomas, thanks for this. > I'm unable to look at it properly but will as soon as I can. > It seems you're running 2 different commands, one for requests data and one > for batches data. > This shouldn't cause any issue, but it's not something I've done before. Heh, I think I'm just used to run it before doing ILL things on my dev env.
Steps to reproduce: 1. Have a fresh KTD 2. Run: $ ktd --shell k$ bash <(curl -s https://raw.githubusercontent.com/ammopt/koha-ill-dev/master/start-ill-dev.sh) k$ cd k$ git clone https://github.com/ammopt/koha-ill-dev.git k$ cd koha-ill-dev/ k$ sudo apt install libdata-faker-perl libtext-lorem-perl k$ PERL5LIB=$PERL5LIB:./lib perl fake_data.pl --how-many 200 --entity ill k$ for x in {1..21}; do echo "INSERT INTO illbatches (name, backend, library_id, status_code, patron_id) VALUES ('$x', 'FreeForm', 'CPL', 'NEW', 52);"; done | koha-mysql kohadev 3. Go to /cgi-bin/koha/ill/ill-requests.pl?method=batch_list 4. Scroll down => FAIL: Koha is your enemy!
Can reproduce (only on Firefox tho, it doesn't happen in Chrome). Firefox throws this console entry: 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!
We probably have a very similar issue, with any DataTables elements with sticky header. Here we found a reference from another reporter, even with video: https://www.datatables.net/forums/discussion/74201 https://www.youtube.com/watch?v=u0_N_GRL--M it's tricky to reproduce, it should be some coincidence of data/table size and window size, so this kinda of pixel-hunting sometimes, but it happens, and it is present and reported by our librarians a lot. We temporarily solved this by disabling "fixedHeader": koha-tmpl/intranet-tmpl/prog/js/datatables.js 53: "fixedHeader": true, -> 53: "fixedHeader": false, but this is only a workaround.
(In reply to Slava Shishkin from comment #5) > We probably have a very similar issue, with any DataTables elements with > sticky header. > > Here we found a reference from another reporter, even with video: > https://www.datatables.net/forums/discussion/74201 > https://www.youtube.com/watch?v=u0_N_GRL--M > > it's tricky to reproduce, it should be some coincidence of data/table size > and window size, so this kinda of pixel-hunting sometimes, but it happens, > and it is present and reported by our librarians a lot. > > We temporarily solved this by disabling "fixedHeader": > > koha-tmpl/intranet-tmpl/prog/js/datatables.js > 53: "fixedHeader": true, > > -> > > 53: "fixedHeader": false, > > but this is only a workaround. We agree, this seems to be a problem anywhere in Koha where DataTables elements with sticky headers are used, for example when using batch deletion of items of a biblio (/cgi-bin/koha/tools/batchMod.pl)
I am moving this to the "Templates" component. I have confirmed the issue on the batch item edit page and seen it on others as well.
Changing importance to major because end of the page can not be accessed.
Can this be linked to Bug 35810 ?
Found this: https://stackoverflow.com/questions/72177644/datatables-fixedheader-gets-confused