NLA viewport jumps upward when track search input is focused #97530

New Issue

System Information
Operating system: Windows 10
Graphics card: NVIDIA GTX 1070

Blender Version
Broken: 3.1
Worked: Unknown

Short description of error
The NLA viewport jumps upward when the track search input box is focused by clicking on it.

Exact steps for others to reproduce the error

Make a bunch of NLA tracks (not necessary, but demonstrates the bug better)
Pan the viewport of the NLA editor down a ways
Click on the track search input box (note that it jumps here!)
Click anywhere else in the UI
Repeat 3 & 4 for bonus marks

**System Information** Operating system: Windows 10 Graphics card: NVIDIA GTX 1070 **Blender Version** Broken: 3.1 Worked: Unknown **Short description of error** The NLA viewport jumps upward when the track search input box is focused by clicking on it. ![nlajumpfocus.gif](https://archive.blender.org/developer/F13015147/nlajumpfocus.gif) **Exact steps for others to reproduce the error** 1. Make a bunch of NLA tracks (not necessary, but demonstrates the bug better) 2. Pan the viewport of the NLA editor down a ways 3. Click on the track search input box (note that it jumps here!) 4. Click anywhere else in the UI 5. Repeat 3 & 4 for bonus marks

Added subscriber: @cmbasnett

Added subscriber: @BClark

Yes little things like that are tiny but cause artists to be nervous that something isn't right, and if something simple like a search bar does this, what else is wrong.. feelings start to appear when the tools are being used!!

Changed status from 'Needs Triage' to: 'Confirmed'

Added subscriber: @PratikPB2123

Did anyone have time to take this on, been making me crazy all week in the NLA

Added subscriber: @nrupsis

This behavior is consistent with the graph editor, and action editor too. All of which call the ED_time_scrub_channel_search_draw method. Still unsure why it's happening...

This behavior is consistent with the graph editor, and action editor too. All of which call the `ED_time_scrub_channel_search_draw` method. Still unsure why it's happening... ![Graph_editor.gif](https://archive.blender.org/developer/F13469368/Graph_editor.gif)

I believe I figured out the cause of this, though I'm not sure how best to fix it.

Basically, the search bar is being anchored to the top, but it is still just part of the channel region (as evidence by the fact you can middle-mouse click the search bar and move the channel view up and down). This is technically no different than, say, a text box on a horizontal toolbar.

There is logic that says when text edit buttons are brought into focus that the view must ensure that the text box is within the bounds of the view, plus padding.

Therefore, when the text box is focused, the view jumps up by the number of padding pixels (around 10 on default settings).

Here is the stack trace of where the bug is occurring.

blender.exe!UI_but_ensure_in_view(const bContext * C, ARegion * region, const uiBut * but) Line 931	C++
blender.exe!ui_textedit_begin(bContext * C, uiBut * but, uiHandleButtonData * data) Line 3452	C
blender.exe!button_activate_state(bContext * C, uiBut * but, uiHandleButtonState state) Line 8301	C
blender.exe!ui_do_but_TEX(bContext * C, uiBlock * block, uiBut * but, uiHandleButtonData * data, const wmEvent * event) Line 4625	C
blender.exe!ui_do_button(bContext * C, uiBlock * block, uiBut * but, const wmEvent * event) Line 8022	C
blender.exe!ui_handle_button_event(bContext * C, const wmEvent * event, uiBut * but) Line 9312	C
blender.exe!ui_region_handler(bContext * C, const wmEvent * event, void * UNUSED_userdata) Line 11276	C
[Inline Frame] blender.exe!wm_handler_ui_call(bContext *) Line 790	C++
blender.exe!wm_handlers_do_intern(bContext * C, wmWindow * win, wmEvent * event, ListBase * handlers) Line 3222	C++
blender.exe!wm_handlers_do(bContext * C, wmEvent * event, ListBase * handlers) Line 3342	C++
[Inline Frame] blender.exe!wm_event_do_handlers_area_regions(bContext *) Line 3788	C++
blender.exe!wm_event_do_handlers(bContext * C) Line 3984	C++
blender.exe!WM_main(bContext * C) Line 643	C
blender.exe!main(int argc, const unsigned char * * UNUSED_argv_c) Line 582	C
[External Code]

Edit: Come to think of it, I think the only good way to fix this would be to reconfigure how the layout of this is done to begin with. The search bar should not be part of the channel region. This would probably also eliminate a lot of jank code that has to account for the space permanently occupied by the search bar.

I believe I figured out the cause of this, though I'm not sure how best to fix it. Basically, the search bar is being anchored to the top, but it is still just part of the channel region (as evidence by the fact you can middle-mouse click the search bar and move the channel view up and down). This is technically no different than, say, a text box on a horizontal toolbar. There is logic that says when text edit buttons are brought into focus that the view must ensure that the text box is within the bounds of the view, **plus padding**. Therefore, when the text box is focused, the view jumps up by the number of padding pixels (around 10 on default settings). Here is the stack trace of where the bug is occurring. ``` blender.exe!UI_but_ensure_in_view(const bContext * C, ARegion * region, const uiBut * but) Line 931 C++ blender.exe!ui_textedit_begin(bContext * C, uiBut * but, uiHandleButtonData * data) Line 3452 C blender.exe!button_activate_state(bContext * C, uiBut * but, uiHandleButtonState state) Line 8301 C blender.exe!ui_do_but_TEX(bContext * C, uiBlock * block, uiBut * but, uiHandleButtonData * data, const wmEvent * event) Line 4625 C blender.exe!ui_do_button(bContext * C, uiBlock * block, uiBut * but, const wmEvent * event) Line 8022 C blender.exe!ui_handle_button_event(bContext * C, const wmEvent * event, uiBut * but) Line 9312 C blender.exe!ui_region_handler(bContext * C, const wmEvent * event, void * UNUSED_userdata) Line 11276 C [Inline Frame] blender.exe!wm_handler_ui_call(bContext *) Line 790 C++ blender.exe!wm_handlers_do_intern(bContext * C, wmWindow * win, wmEvent * event, ListBase * handlers) Line 3222 C++ blender.exe!wm_handlers_do(bContext * C, wmEvent * event, ListBase * handlers) Line 3342 C++ [Inline Frame] blender.exe!wm_event_do_handlers_area_regions(bContext *) Line 3788 C++ blender.exe!wm_event_do_handlers(bContext * C) Line 3984 C++ blender.exe!WM_main(bContext * C) Line 643 C blender.exe!main(int argc, const unsigned char * * UNUSED_argv_c) Line 582 C [External Code] ``` Edit: Come to think of it, I think the only good way to fix this would be to reconfigure how the layout of this is done to begin with. The search bar should not be part of the channel region. This would probably also eliminate a lot of jank code that has to account for the space permanently occupied by the search bar.

Added subscriber: @dr.sybren

In #97530#1450613, @cmbasnett wrote:
Edit: Come to think of it, I think the only good way to fix this would be to reconfigure how the layout of this is done to begin with. The search bar should not be part of the channel region. This would probably also eliminate a lot of jank code that has to account for the space permanently occupied by the search bar.

Without knowing much about the UI code, that looks like the right way to go for me, indeed.

> In #97530#1450613, @cmbasnett wrote: > Edit: Come to think of it, I think the only good way to fix this would be to reconfigure how the layout of this is done to begin with. The search bar should not be part of the channel region. This would probably also eliminate a lot of jank code that has to account for the space permanently occupied by the search bar. Without knowing much about the UI code, that looks like the right way to go for me, indeed.

I've posted a question on the devtalk forums about how best to fix this: https://devtalk.blender.org/t/fixing-artificial-header-ui-in-animation-editors/26753

Following up here now that it is in the new system

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

NLA viewport jumps upward when track search input is focused #97530