Was paging of this view ever supported? Can we support it or should we just hide the navbar?

Even if "paging" can't be supported, perhaps the "number of results" option could be put in to the input controls then?

It has never worked, AFAICS, since it requires explicit handling of the "offset" (and "limit") query parameters.

In T292764#7433694, @Daimona wrote:

It has never worked, AFAICS, since it requires explicit handling of the "offset" (and "limit") query parameters.

It does! You can just send dir, offset, and limit along with the form data in the POST request and it returns what you expect. I just wrote a script to demonstrate this (though I'm sure a solution would be form elements instead of links).

In T292764#7607860, @Nardog wrote:

In T292764#7433694, @Daimona wrote:

It has never worked, AFAICS, since it requires explicit handling of the "offset" (and "limit") query parameters.

It does! You can just send dir, offset, and limit along with the form data in the POST request and it returns what you expect. I just wrote a script to demonstrate this (though I'm sure a solution would be form elements instead of links).

Interesting finding. I haven't tested it, but judging from the code, AbuseFilterExaminePager inherits from ReverseChronologicalPager -> IndexPager, where these values are indeed retrieved from the request (and even user's preferences).

So to summarize:

1. The navigation bar is dummy and doesn't work because the form only returns results after POST.
2. You can manually craft a POST request which can change the limit, offset, etc.
   • There is a hard limit of 5000 that cannot be exceeded. I can see no risk of private info leaks.
3. Unless you use Nardog's hack, the limit of shown results depends on your preferences (rclimit).
4. The output HTML is somewhat broken:

<div class="mw-changes-list">
 (top navbar)
 <h4>...</h4>
 <ul>...</ul>
 [...]
 <ul>
  <li>...</li>
  [...]
  (bottom navbar)
 </ul>
</div>

So we can either remove the navbar and override (disable) the request parameters (and perhaps add an option for the limit) or implement the paging using AJAX.

There are forms that have "Items per page:" (AllMessages, BlockList, ListFiles...) so this too could mimic them. The TablePager-style buttons (First page/Previous page/Next page/Last page) would also fit.

But why does this use POST and require a token in the first place? I get it for individual edits (/examine/log/...) because the filter code needs to be sent which can be big, but AFAICS the /examine form isn't much different from AbuseLog, Contributions, Watchlist, etc. The request isn't big, and you don't even have to log in to see it.