Viewing more questions per page (15 > 30 > 50) will cause you to jump past the "end of the book" showing "page not found".

Steps to reproduce:

  • View newest questions, page size 15 (link)
  • Jump to older-questions page, page size 15 (link)
  • Switch to 50 questions per page (link)

Note: A search for this bug turned up an mishmash of closed, migrated, deleted, and [status-completed] posts, so I'm not sure this is documented at all. I tried to clean up and consolidate. Here ya go.

  • Behavior should probably be as with the normal questions lists, where going past the end just gives you an empty list (with the pager links clearly showing what the last page actually is).
    – Shog9
    Commented Oct 26, 2012 at 15:22
  • Hmm... That may be missing the point. I don't think most users want to view page 259273, literally. They're looking at a list of questions. The normal use case is to show the same list of questions, only longer. Commented Oct 26, 2012 at 15:31
  • So, redirect them to the last valid page?
    – Shog9
    Commented Oct 26, 2012 at 15:33
  • Hmm, did the page size links always include the current page number? For some reason I thought it used to always bump you back to the first page, which obviously avoids this problem.
    – Tim Stone
    Commented Oct 26, 2012 at 15:43
  • @Shog9 Perhaps... if that's the way it (just happens) to work out. But every pagination routine I've ever written said "start with item [X] and show 15." Switching it to 50 means simply "start with item [X] and show 50." Typically you don't want to stay on the same literal page number and show whatever happens fall there. Think about changing the page size in your word processor. You don't suddenly see a different part of the document because you are viewing page 15. It just "re-pages" the same bit of text you are looking at. (Wasn't planning on getting into a design discussion) Commented Oct 26, 2012 at 15:43

1 Answer 1


The problem was here:

Regex _removePage = new Regex(@"page=\d+&", RegexOptions.Compiled);

We used to ensure the page was stripped off the page sizer's URL, effectively kicking you back to page 1 in all cases. When we switch to razor and no longer had to encode the URLs in our strings, & became & and the stripping of page number just silently stopped working.

It's gotten a refactor under the covers to simplify things, but the old behavior should be back - this will happen in the next build.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .