search

Ericsson / codechecker

CodeChecker is an analyzer tooling, defect database and viewer extension for the Clang Static Analyzer and Clang Tidy
https://codechecker.readthedocs.io
Apache License 2.0
2.15k stars 358 forks source link

[web] Changing of filters and the reset of the page in the Reports table does not adjust the `page=` GET parameter, which can lead to out of bounds visualisation when used as a permalink or through the "Back to Reports" button #4206

Open whisperity opened 3 months ago

whisperity commented 3 months ago

Describe the bug The user's choice on which page they are during the pagination of the reports is kept even when the filters change and the selected page is now out of bounds.

CodeChecker version 6.23 release

To Reproduce Steps to reproduce the behaviour:

  1. Store many reports in a way that you can filter for a "large" and a "small" set.
    • Preferably, the "large" set should be larger than the page size and the small set should be smaller than the page size. In this concrete example, I'm using 50 as the page size, the large set is 917 elements, and the small set is 28. (So a 25 page size would not suffice!)
  2. Filter for the "large" set and go some pages forward in the report list,
  3. Now change the filters such that the "small" set is filtered.
  4. Observe that the filter now shows the small set properly (e.g., in my example, 50 rows per page, showing the "1-28 of 28" results), but the URL still says &page=4.
    • (I can't directly link this step, because that way, the observation would differ!)
  5. The report page works and shows the newly filtered data, open a report at random.
  6. Use the "Back to Reports" button such that you return to the report list.
  7. Now the report list says No data available, Rows per page: 50, 1-0 of 28 (this is strange!), because we are still on &page=4, as seen in the URL.
  8. The user has to click the < button 3 times (because we are on page 4, but there is no indication of this fact anywhere except if mined from the URL!) to get back to the "normal" result page.

Expected behaviour The filter reapplies after detecting that it's on the wrong page OR when fixing the filtered list in step 3, the &page= in the GET params is set to 1 or something.

Desktop (please complete the following information)