-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug: Custom listener + consuming insets #102
Comments
Aha! So that's why it broke for me after upgrade. I heavily rely on custom listener in my setup. Any chance this will be released soon? |
Friendly ping @chrisbanes. Currently have to use an obsolete library version and also getting a lot of insets-related Do you plan on releasing a new minor version in the near future? |
My bad, I’ll release a new version tomorrow! |
Hurray, thank you! |
In method
applyToView
and checking for custom listener, there's probably a bug with checking if insets should be consumed.insetter/library/src/main/java/dev/chrisbanes/insetter/Insetter.kt
Line 373 in 2724d46
The problem is in the if condition - it should be reverted and therefore
if(consume == CONSUME_NONE) insets else WindowInsetsCompat.CONSUMED
because when none consumed, then we should return the initial insets, right?This breaks insetter when custom listener is applied somewhere in the view hierarchy.
The text was updated successfully, but these errors were encountered: