SetScrollHereY() does not behave as expected when content size is expanded (but not reduced)

[wolfpld]

Revision 05bc204.

Consider the following code:

        static int lines = 100;
        static int focus = -1;

        ImGui::Begin( "test" );
        if( ImGui::Button( "100 lines, focus 50" ) )
        {
            lines = 100;
            focus = 50;
        }
        ImGui::SameLine();
        if( ImGui::Button( "1000 lines, focus 500" ) )
        {
            lines = 1000;
            focus = 500;
        }
        ImGui::SameLine();
        if( ImGui::Button( "2000 lines, focus 50" ) )
        {
            lines = 2000;
            focus = 50;
        }
        ImGui::BeginChild( "###list", ImVec2( 0, 0 ), true );
        for( int i=0; i<lines; i++ )
        {
            if( i == focus )
            {
                ImGui::SetScrollHereY();
                focus = -1;
            }
            ImGui::Text( "Line %i", i );
        }
        ImGui::EndChild();
        ImGui::End();

This will display a list of items. The number of displayed items can be changed (which also changes size of scrollable content area). We also want to focus view on a particular item on the list - this action is not behaving as expected.

There are basically two cases here:

1. 100 lines are displayed, but we want to expand that to 1000 lines and focus on line 500.
2. 2000 lines are displayed, and we want to reduce that to 1000 lines and focus on line 500.

In the first case, instead of focusing on line 500, focus lands on line ~300 (the Y position is misaligned in comparison to the successful focusing actions). This happens regardless of the initial scroll position. However, if focusing action is repeated (with no change to number of lines, which stays at 1000), focus lands on line 500, as expected.

In the second case, focus always lands on line 500.

[ocornut]

Thank you Bartosz for the nice bug report, as always.

Looks like this was caused by 473a01a, I made a mistake processing the edge snap in the calling frame. Should fix shortly.

[ocornut]

Pushed a fix for it now.
You may merge latest master in docking, or cherry-pick those two commits: 8db94cd (misc renaming) and 70289ab (actual fix).

[wolfpld]

Thanks!