The long & short of the reason why this happens is because the search bar is simply a part of the view region and is artificially being anchored to the top of the view in the draw code. When the text box is focused, it attempts to make sure the text box plus padding is totally visible in the region, hence the jumping behaviour.
To fix this, my initial thought was naturally to separate the channel area and the text box into separate UI areas. So I thought maybe I could make it so that the channel region has its own header that I could put the filter in, but it seems like a “space” can only have one header. Is there any precedent for this kind of “second header” separation in Blender? How might I accomplish this?
It needs a change in the UI code, but developers working on modules will generally need to touch various parts of the code that are shared between modules. So I was expecting @cmbasnett to either implement a fix or ask for more help.
An alternative fix could be to not scroll the 2D view if the button is fully visible without padding, and only when it’s not fully visible to scroll it into view with padding. That’s probably reasonable behavior also in other UI regions, and easy to implement.
To make it completely ignore the 2D view for such a float button I imagine it a new UI_BLOCK_ flag would be added to uiBlock to indicate a UI region with absolute position. That’s probably a relatively simple change as well.
I was hoping that there would be a way to create a hierarchy within these UI “areas” and have the text box live in it’s own region, and the channel list would be in a separate region entirely, so there would be no strange interactions like this. Having looked through the UI code, it seems this isn’t really possible.
I think the flag option is probably the best approach since it can be focused on fixing this particular scenario instead of modifying the behaviour across Blender.