Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-72964

Table of warning namespaces/packages shows only first page

      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.

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

          Ulli Hafner added a comment -

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

          Ulli Hafner added a comment - Can you please add a screenshot? On my machine this looks fine, see my screenshot.

          Ulli Hafner added a comment -

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

          Ulli Hafner added a comment - Are the dom elements visible when you open the browser inspector?

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

          Kalle Niemitalo added a comment - Only page number 1 is initially in the DOM. The others are added to the DOM during the resize event.

          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.

          Kalle Niemitalo added a 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.

          Kalle Niemitalo added a comment - Possibly related thread: DataTables 2 and pagination button styles — DataTables forums

          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?

          Kalle Niemitalo added a 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?

          Ulli Hafner added a 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?

          Ulli Hafner added a 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?

          Kalle Niemitalo added a comment - - edited

          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.

          Kalle Niemitalo added a comment - - edited 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 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.

          Kalle Niemitalo added a 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.

            Unassigned Unassigned
            kon Kalle Niemitalo
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: