UI bug - tab key does not advance cursor to the next input field

This happens, for example, with SubDBox or BoxEdit and its numerical input fields. Instead, the user has to click into each.

Version 8 (8.23.25251.13002, 2025-09-08)

yes that is a freaking mess and i have reported it a million years ago, it happens basically in all commands that have a text field. i cant find the initial topic i believe i have created but here is one more or less recent (4 years ago) but i am quite certain i posted that issue in my former life here many more years earlier.

in the commands below (there might be more but i am not going to dissect them all) the cursor advances to the arrows instead to the next text field which is probably 999,99% useless?

for instance:

Rebuild
Patch
BoxEdit
Mesh
BlendSrf (here it jumps to the lever which makes the same zero sense.)

SubDBox is similar, here tab only confirms the entered choice and then you have to click on the next field which is basically 300% useless and an extreme flow breaker. Tab is globally and in every app i know of intended for getting to the next text field swiftly to hit in the numbers.

it is one of the most infuriating things that never got fixed in the history of Rhinos UI. there are multiple topics regarding this issue, McNeel Staff showed up but i never ever saw anyone logging a tracker. or taking it serious.

i am just rude and imagine out loud how everyone one of the developers is using the mouse for everything even for arrows to increase numbers, i assume there are no real power users which have to work fast amongst them, otherwise it would have been fixed 999.999 years ago.