Material-components-android: [BottomAppBar] Eager padding setting

[diareuse]

Description:
After updates to newest versions throughout Google's portfolio I'm encountering issue which regards consuming insets.
Since the widget applies padding to itself to counteract the window's navigation and status areas' size taken on the screen it does so in a very weird way.

If I'm consuming the insets, the padding is implicitly set to 0 by the widget - initialPadding being 0 (incorrectly) to which is added 0 as remainder of the consumed insets (correctly).
When I'm not consuming any insets, the padding is set to 192 by the widget - initialPadding being 96 (incorrectly) to which is added 96 as remainder of consumed insets (correctly).

I'd speculate that this issue is partly caused by upstream libraries (such as core or appcompat) which might've altered the logic behind the OnApplyWindowInsetsListener and its respective callers.

Expected behavior:
The BAB respects the initial padding set by other sources and peeks the remainder of systemWindowInsets and adds it to current padding if explicitly called for.

Source code:

    <style name="ThemeFoundation" parent="Theme.MaterialComponents.NoActionBar">
        <item name="android:windowTranslucentStatus">true</item>
        <item name="android:windowTranslucentNavigation">true</item>
    </style>

* any BAB in activity's root layout is having this issue, so omitted for brevity

Android API version:
28,29 - possibly any other as well

Material Library version:
1.1.0-alpha10

Device:
Emulator, OnePlus 6T

[craftingmod]

Have you tried this code to cancel applywindowinsets? (bottomBar to your BottomAppBarLayout)

    ViewUtils.doOnApplyWindowInsets(bottomBar, object : ViewUtils.OnApplyWindowInsetsListener {
      override fun onApplyWindowInsets(view: View?, insets: WindowInsetsCompat?, initialPadding: ViewUtils.RelativePadding?): WindowInsetsCompat {
        return insets!!
      }
    })

Maybe simirar issue with me #564

[diareuse]

@craftingmod would it change the fact that its dependency might be misbehaving?

Please see the bug description, I'm specifying that I'm getting values, through the compat util, that are wildly inaccurate resulting in this particular bug. Adding the override wouldn't do much good.

[craftingmod]

That listener modifes padding at their own but I misread your topic, sorry

[cketcham]

Insets are kind of hard to deal with and there are a few proposals for fixing it like https://github.com/chrisbanes/insetter, when something like that becomes available, it might be better to handle the insets completely outside of our components. For now we have to try to give a good experience with what we have.

Based on what I think you're asking, I'm not sure if I agree if your expected behavior is what I would expect.

For instance if you set the bottom padding for the BottomAppBar to 36dp, after the insets are applied, I think I'd want bottom inset + 36dp padding. Are you saying that you think the padding should be set to just the bottom inset?

[diareuse]

Are you saying that you think the padding should be set to just the bottom inset?

No, that was not what I was trying to say, unfortunately.

Since, as you pointed out the insets are being inconsistent, I'd set the padding myself in activity, consume it in my fragment and in some situations the BottomAppBar manages to apply the insets before they are consumed by the fragment. Effectively doubling the amount of the padding.

So I was suggesting it would be fair to enable this behavior via some xml attribute by explicitly called for.