Status Update
Comments
ki...@google.com <ki...@google.com> #2
Thanks for the detailed analysis and sample. I've prepared a CL, but I'd also be happy to review an external contribution since you already went through the trouble of identifying a fix. Just let me know here.
ki...@google.com <ki...@google.com> #3
If you have a CL ready go for it.
That being said, I just went down git history and found when this was introduced:
As you can see, this was introduced to fix a "memory leak" though I don't quite understand why creating a new callback wrapper for every setSupportActionBar()
call is a problem.
he...@ataulm.com <he...@ataulm.com> #4
Branch: androidx-main
commit 200ccecbc8c7c5ba555e7fa15890edff67affb58
Author: Alan Viverette <alanv@google.com>
Date: Fri Apr 30 14:55:07 2021
Fix case where setSupportActionBar overwrites the window callback
RelNote: """Fix scenario where calling setSupportActionBar after setting the
window callback would overwrite the callback."""
Test: SupportActionBarTestCase
Fixes: 186791590
Change-Id: Ie43eedf8322caa44e7b201a95cbc64197953e020
A appcompat/appcompat/src/androidTest/java/androidx/appcompat/app/SupportActionBarTestCase.kt
M appcompat/appcompat/src/main/java/androidx/appcompat/app/AppCompatDelegateImpl.java
ki...@google.com <ki...@google.com> #5
he...@ataulm.com <he...@ataulm.com> #6
I vaguely remember this. The issue was iirc:
- You use multiple fragments (say switched via tabs). Each fragment calls
setSupportActionBar()
when visible. - The old code would wrap the current
Window.Callback
with something fromToolbarActionBar
(TAB), then set it as the window callback. - When the user switches to Tab #2, we'd do the same thing, but this time the callback wrapper chain would be
(((Root callback) TBAB1Wrapper) TBAB2Wrapper)
. TBAB1Wrapper would keep a reference a reference to the views even though the #1 fragment has likely been destroyed.
I've just +2'd Alan's CL, but the proper fix is properly to unwrap the callback from Window.getCallback()
.
ki...@google.com <ki...@google.com>
ki...@google.com <ki...@google.com> #7
Let me uh... let me go back and properly fix that.
ap...@google.com <ap...@google.com> #8
One thing though, you can't quite unwrap because there's no guarantee you'll get the same callback (e.g. it might have been wrapped again).
It seems like what we want here is:
- ensure the callback is set at least once
- get a reference to it later
Is there a way the internal code can keep a ref to that new callback once its set, and reference it instead of installing or unwrap?
Description
androidx.appcompat:appcompat
1.2.0-beta01
Theme.MaterialComponents.Light.NoActionBar
Issue
Setting the text appearance programmatically with
TextViewCompat.setTextAppearance(TextView, Int)
on anAppCompatEditText
does not take into account theme attrs being used inColorStateList
asandroid:textColorHint
(orandroid:textColorLink
).So on Lollipop, such a hint color is rendered as red (see screenshot).
Cause
Internally, it delegates to
AppCompatTextHelper.onSetTextAppearance
, which doesn't handle these two attributes - it only considersandroid:textColor
:However, it does consider them in
loadFromAttributes()
so it seems like it's an oversight.Feature request/bug fix
Update
AppCompatTextHelper
to handle theme attributes in CSLs forandroid:textColorHint
andandroid:textColorLink
inonSetTextAppearance()
as it's done inloadFromAttributes()
.Workaround
For folks in the meantime - call this too, after calling
TextViewCompat.setTextAppearance()
.