@Lazeez Jiddan (Webmaster)tl;wr I think it's not quite right, but is good enough as-is.
after they leave the field, the reload would get triggered
- but it doesn't always:
Typing a new page number then clicking away from the field/control works as you describe.
Clicking on the page number entry field, then using the spin box arrows to select a new page number, then clicking away from the control works as you describe.
Using the spin box arrows to select a new page number without clicking anything else first, then clicking away from the control (or hitting Enter) does nothing: the entry field shows the selected page number, but nothing is loaded.
Using the spin box arrows to select a new page number, then clicking on the newly selected page number (not on the arrows), then clicking away from the control is required to load the new page. This two-click process is what I think is a bit clunky (and obviously reloading the page on every arrow click is a Very Bad Idea).
For completeness, the above failure only occurs if the entry field has NOT been selected before clicking on the spin box arrows (i.e., the text caret is not flashing in the page number spin box field); if you click on the numeric field next to the spin box arrows before, during or after using the arrows the page loads correctly on clicking away from the control. So to demonstrate this issue, load a suitable author page from the authorlist pages or any other method, then without clicking anything else use the spin box arrows to select a different page, then click away from the control; compare this behaviour with performing the same actions but also clicking on the spin box numeric field at any time between loading the page and clicking away from the field.
Actually the quote highlighted above is correct if you regard the spin box arrows as being neither in nor out of the field (which seems a bit odd). I think the easiest fix would be to put in something like a set_focus() to the entry field when either arrow is clicked, or setting the arrow or spin box attributes to make that happen. A different workaround would be to hide (or grey out) the arrows if the control does not have focus, and to by default set focus to the current page numbered button on page load. Of course, it may be a bug in the underlying JavaScript control library, but either way the above focus shenanigans will make it behave more logically.
It's really an issue of UI design; the reader using the spin box arrows would normally expect use of the arrows to focus on the control, and has no way (apart from reading these forums) of knowing the requirement to click in the edit control before hitting Enter or clicking away from the control, and the (lack of) caret in the edit box is a subtle indicator, so it becomes somewhat of a hidden variable problem leading to inconsistent user experience and probably avoidance of the feature. On the gripping hand, there aren't many authors with enough stories to make using this feature faster than just click-to-load on the highest available page a few times, instances of wanting to go to a particular page or region rather than sequential browsing will be relatively rare, and it only takes a handful of seconds for me to realise I've been caught out again and to click in-then-out of the control to trigger a reload. So, just ignore me.