Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Skip to content
Commit f4951023 authored by Andy Wickham's avatar Andy Wickham
Browse files

Ensure header view expected height accounts for tabs.

This was already handled except for the case where there were no
predicted apps and no all apps divider, i.e. suggested apps are
disabled and a work profile is added (so tabs show instead of the
divider).

Why did the other cases work? Predicted apps and the divider are
FloatingHeaderRows which call FloatingHeaderView#onHeightUpdated
whenever they are updated (triggering updateExpectedHeight()).

And why did this sometimes "fix itself" until a reboot? When the
search bar is tapped, the search transition causes the expected
height to be updated. So that is my guess.

The key to this change is to wait to update the expected height
until after we have defined mTabsHidden during setup(). It is
normal for the header to be initialized without tabs and then
updated to show the tabs when the work apps are available. So
this was previously incorrectly using mTabsHidden=true for the
calculations.

Fix: 245516031
Test: Manual (force stop launcher and verify tabs scroll correctly)
Flag: NA
Change-Id: Ifcc2f39649c5494b5f3ebefc1cdddfbefbe5d9a0
parent 60dcb19a
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment