[JENKINS-72964] Table of warning namespaces/packages shows only first page

[jenkins-infra-bot]

I have a project in which the MSBuild warnings parser finds a total of 60 warnings in 30 namespaces.  When the Warnings plugin shows the list of namespaces that have warnings:

• Initially, it has "10 entries per page".  The bottom line says "Showing 1 to 10 of 30 entries" as expected; but the page selector at the bottom right corner lists only page 1.  The page selector should list pages 1, 2, and 3.
• Then, I select "25 entries per page".  The bottom line says "Showing 1 to 25 of 30 entries" and the page selector correctly lists pages 1 and 2.
• Then, I select "10 entries per page" again.  The bottom line says "Showing 1 to 10 of 30 entries" and the page selector correctly lists pages 1, 2, and 3.

---

Originally reported by kon, imported from: Table of warning namespaces/packages shows only first page

• status: Open
• priority: Minor
• component(s): data-tables-api-plugin, warnings-ng-plugin
• label(s): help-wanted
• resolution: Unresolved
• votes: 0
• watchers: 2
• imported: 2025-12-09

Raw content of original issue

I have a project in which the MSBuild warnings parser finds a total of 60 warnings in 30 namespaces.  When the Warnings plugin shows the list of namespaces that have warnings:

	
Initially, it has "10 entries per page".  The bottom line says "Showing 1 to 10 of 30 entries" as expected; but the page selector at the bottom right corner lists only page 1.  The page selector should list pages 1, 2, and 3.
	
Then, I select "25 entries per page".  The bottom line says "Showing 1 to 25 of 30 entries" and the page selector correctly lists pages 1 and 2.
	
Then, I select "10 entries per page" again.  The bottom line says "Showing 1 to 10 of 30 entries" and the page selector correctly lists pages 1, 2, and 3.

environment

Jenkins 2.440.2<br/>
warnings-ng 11.2.2<br/>
data-tables-api 2.0.2-1

3 attachments

• Bildschirmfoto 2024-08-21 um 14.42.46.png

  

• image-2024-08-22-08-08-06-280.png

  

• redacted 67 warnings in 33 namespaces page 1 only.png

  

[jenkins-infra-bot]

kon:

• Original comment link
• Raw content of original comment:

  I upgraded to data-tables-api 2.0.3-1 and still get the same bug.
  

I upgraded to data-tables-api 2.0.3-1 and still get the same bug.

[jenkins-infra-bot]

drulli:

• Original comment link
• Raw content of original comment:

  Is this still a problem? I cannot reproduce this issue...
  

Is this still a problem? I cannot reproduce this issue...

[jenkins-infra-bot]

kon:

• Original comment link
• Raw content of original comment:

  Yes, this is still a problem.  With Mozilla Firefox 115.14.0esr, and also with Microsoft Edge 127.0.2651.105.
  
  However!  If I resize the Web browser window, then the missing page numbers appear in the page selector, even though there is no new HTTP request.  So the client-side JavaScript apparently has all the information it needs, but does not initially display it correctly.
  

Yes, this is still a problem. With Mozilla Firefox 115.14.0esr, and also with Microsoft Edge 127.0.2651.105.

However! If I resize the Web browser window, then the missing page numbers appear in the page selector, even though there is no new HTTP request. So the client-side JavaScript apparently has all the information it needs, but does not initially display it correctly.

[jenkins-infra-bot]

drulli:

• Original comment link
• Raw content of original comment:

  Can you please add a screenshot? On my machine this looks fine, see my screenshot. 
  

Can you please add a screenshot? On my machine this looks fine, see my screenshot.

[jenkins-infra-bot]

drulli:

• Original comment link
• Raw content of original comment:

  Are the dom elements visible when you open the browser inspector?
  

Are the dom elements visible when you open the browser inspector?

[jenkins-infra-bot]

kon:

• Original comment link
• Raw content of original comment:

  Only page number 1 is initially in the DOM.  The others are added to the DOM during the resize event.
  

Only page number 1 is initially in the DOM. The others are added to the DOM during the resize event.

[jenkins-infra-bot]

kon:

• Original comment link
• Raw content of original comment:

[jenkins-infra-bot]

kon:

• Original comment link
• Raw content of original comment:

  Tried to debug this in the browser, by overriding dataTables.min.js with dataTables.js.
  
  On the first _pagingDraw call, settings._bInitComplete is undefined.
  
  On the second _pagingDraw call, visRecords == 33, len == 10, and pages == 4. It makes a recursive call to _pagingDraw(settings, host, $.extend({}, opts, { buttons: opts.buttons - 2 })).
  
  On the third _pagingDraw call (nested), opts.buttons == 5. It makes a recursive call again because $(host).height() is 0 and $(buttonEls[0]).outerHeight() is 0. I guess the zero height may be caused by the CSS rule .tab-content > .tab_page { display: none } in bootstrap-custom-build.css.
  
  On the fourth _pagingDraw call (doubly nested), opts.buttons == 3.  Now the buttons array has only 3 items, and the function makes 3 elements in buttonEls.  There's a recursive call again.
  
  On the fifth _pagingDraw call (triply nested), opts.buttons == 1, and buttonEls has only one element in it.  No recursive call this time.
  
  All the nested _pagingDraw calls return, to the draw function in the 'paging' feature registration.
  
  —
  
  Each time I resize the browser window, it corrects the page number buttons in the active tab ("Namespaces", "Files", "Categories", or "Issues") but removes almost all page number buttons in each inactive tab.
  

Tried to debug this in the browser, by overriding dataTables.min.js with dataTables.js.

On the first _pagingDraw call, settings._bInitComplete is undefined.

On the second _pagingDraw call, visRecords == 33, len == 10, and pages == 4. It makes a recursive call to _pagingDraw(settings, host, $.extend({}, opts, { buttons: opts.buttons - 2 })).

On the third _pagingDraw call (nested), opts.buttons == 5. It makes a recursive call again because $(host).height() is 0 and $(buttonEls[0]).outerHeight() is 0. I guess the zero height may be caused by the CSS rule .tab-content > .tab_page { display: none } in bootstrap-custom-build.css.

On the fourth _pagingDraw call (doubly nested), opts.buttons == 3. Now the buttons array has only 3 items, and the function makes 3 elements in buttonEls. There's a recursive call again.

On the fifth _pagingDraw call (triply nested), opts.buttons == 1, and buttonEls has only one element in it. No recursive call this time.

All the nested _pagingDraw calls return, to the draw function in the 'paging' feature registration.

—

Each time I resize the browser window, it corrects the page number buttons in the active tab ("Namespaces", "Files", "Categories", or "Issues") but removes almost all page number buttons in each inactive tab.

[jenkins-infra-bot]

kon:

• Original comment link
• Raw content of original comment:

  Possibly related thread: DataTables 2 and pagination button styles — DataTables forums
  

Possibly related thread: DataTables 2 and pagination button styles — DataTables forums

[jenkins-infra-bot]

kon:

• Original comment link
• Raw content of original comment:

  So: my current theory is that the responsive paging code at the end of the _pagingDraw function causes the problem when the data table is nested within the tab selector thingy that uses the display: none style for inactive tabs.  Initially, all tabs are inactive and _pagingDraw mismeasures the height as zero and tries to make the page-number buttons fit in the zero height, by removing almost all of them.  After the page has been fully loaded and one of the tabs has become active, if I resize the browser window, then the correct page numbers appear in that tab, as the display: none style no longer applies and _pagingDraw is now able to measure the height correctly.
  
  I'm not sure the responsive paging stuff is at all necessary here; but I don't see an easy way to disable it either.
  
  Perhaps this can instead be fixed by somehow forcing the data table to refresh its page number buttons each time a tab becomes active.
  
  Why don't your web browsers show the same problem, though?
  

So: my current theory is that the responsive paging code at the end of the _pagingDraw function causes the problem when the data table is nested within the tab selector thingy that uses the display: none style for inactive tabs. Initially, all tabs are inactive and _pagingDraw mismeasures the height as zero and tries to make the page-number buttons fit in the zero height, by removing almost all of them. After the page has been fully loaded and one of the tabs has become active, if I resize the browser window, then the correct page numbers appear in that tab, as the display: none style no longer applies and _pagingDraw is now able to measure the height correctly.

I'm not sure the responsive paging stuff is at all necessary here; but I don't see an easy way to disable it either.

Perhaps this can instead be fixed by somehow forcing the data table to refresh its page number buttons each time a tab becomes active.

Why don't your web browsers show the same problem, though?

[jenkins-infra-bot]

drulli:

• Original comment link
• Raw content of original comment:

  I see. Maybe we can add a redraw for the tables when a tab is selected. 
  
  
  
  Why don't your web browsers show the same problem, though?
  
  
  I don't know. I never experienced such a problem, also no other user reported it. Can you see this problem on one of the results in ci.jenkins.io?
  
  

I see. Maybe we can add a redraw for the tables when a tab is selected. 

Why don't your web browsers show the same problem, though?

I don't know. I never experienced such a problem, also no other user reported it. Can you see this problem on one of the results in ci.jenkins.io?

[jenkins-infra-bot]

kon:

• Original comment link
• Raw content of original comment:

  I see a similar problem at https://ci.jenkins.io/job/Tools/job/jenkinsfile-runner/job/release-cycle-fix/1/analysis/, but it's a bit more complex to reproduce.
  
  	
  Open the page. Initially, the "Modules" tab is selected, and it displays "Showing 1 to 3 of 3 entries". Page number 1 is shown.
  	
  Select the "Issues" tab. It loads the table rows from the server, displays "Showing 1 to 10 of 40 entries", and shows page numbers 1 to 4. Correct so far.
  	
  Select the "Modules" tab again. It shows the same as before.
  	
  Resize the Web browser window (and optionally resize it back). No change.
  	
  Select the "Issues" tab again. It displays "Showing 1 to 10 of 40 entries" and only page number 1.
  
  
  
  

I see a similar problem at https://ci.jenkins.io/job/Tools/job/jenkinsfile-runner/job/release-cycle-fix/1/analysis/, but it's a bit more complex to reproduce.

1. Open the page. Initially, the "Modules" tab is selected, and it displays "Showing 1 to 3 of 3 entries". Page number 1 is shown.
2. Select the "Issues" tab. It loads the table rows from the server, displays "Showing 1 to 10 of 40 entries", and shows page numbers 1 to 4. Correct so far.
3. Select the "Modules" tab again. It shows the same as before.
4. Resize the Web browser window (and optionally resize it back). No change.
5. Select the "Issues" tab again. It displays "Showing 1 to 10 of 40 entries" and only page number 1.
   

[jenkins-infra-bot]

kon:

• Original comment link
• Raw content of original comment:

  I wonder if this could be patched in _pagingDraw in data-tables.  Make it skip the recursive call if the height is zero; and set up a ResizeObserver to redo _pagingDraw if the height becomes nonzero later.  I'm not a web UI developer though, so I don't know whether it can be implemented that way.
  

I wonder if this could be patched in _pagingDraw in data-tables. Make it skip the recursive call if the height is zero; and set up a ResizeObserver to redo _pagingDraw if the height becomes nonzero later. I'm not a web UI developer though, so I don't know whether it can be implemented that way.

[jenkins-infra-bot]

[Original duplicates from Jira: JENKINS-74833]