Fixed
Status Update
Comments
mi...@gmail.com <mi...@gmail.com> #2
[Comment deleted]
ch...@google.com <ch...@google.com> #3
We're still trying to work out if we can work around this in the library.
In the mean-time, if you know that you are going to create a WebView in an Activity, you can do the following:
protected void onCreate(Bundle savedInstanceState) {
if (Build.VERSION.SDK_INT >= 24) {
new WebView(this);
}
super.onCreate(savedInstanceState);
}
In the mean-time, if you know that you are going to create a WebView in an Activity, you can do the following:
protected void onCreate(Bundle savedInstanceState) {
if (Build.VERSION.SDK_INT >= 24) {
new WebView(this);
}
super.onCreate(savedInstanceState);
}
mn...@gmail.com <mn...@gmail.com> #4
alternatively you were able to get it to work by capturing the configuration prior to inflating a webview and restoring it after
Configuration oldConfig = getCurrentConfig();
//**inflate webview here**
restoreConfig(oldConfig);
Configuration getCurrentConfig() {
return new Configuration(activity.getResources().getConfiguration());
}
void restoreConfig(@Nullable Configuration configuration) {
//if the config isn't null, a webview was inflated and we should update the configuration to
//the previous one to prevent nightmode from being reset by webview inflation
if (configuration != null) {
activity.getResources().updateConfiguration(configuration, null);
}
}
Configuration oldConfig = getCurrentConfig();
//**inflate webview here**
restoreConfig(oldConfig);
Configuration getCurrentConfig() {
return new Configuration(activity.getResources().getConfiguration());
}
void restoreConfig(@Nullable Configuration configuration) {
//if the config isn't null, a webview was inflated and we should update the configuration to
//the previous one to prevent nightmode from being reset by webview inflation
if (configuration != null) {
activity.getResources().updateConfiguration(configuration, null);
}
}
ch...@google.com <ch...@google.com> #5
#3: That can work, but you don't want to do that on EVERY WebView inflate, only the first. My workaround is #2 is a one-time call.
mn...@gmail.com <mn...@gmail.com> #6
We have webviews in recycler view. Until we wrapped every call we would get zebra stripping on recycling. Thanks for looking into issue overall!
jo...@nuzzel.com <jo...@nuzzel.com> #7
Any updates or more details on this Issue?
We were stuck for a few days trying to implement DayNight via AppCompat within our app. On API 24+ our Main activity, which hosts a ViewPager, was not being properly themed. We had inconsistent behavior on the inner fragments within the view pager hosting recycler views where they were either not themed for night mode or some items where partially getting themed. It was not until I found this issue that I was able to connect the dots as our ViewPage hosts a WebView within one of the fragments.
After adding the work around for the onCreate, we are now able to take advantage of this Support Lib feature but would like to know more about what is going on and what should we watch out moving forward. Specially as we have some devices already running Android O beta and the night theme for reasons unknown yet was not applied to some textviews.
further details are much appreciated.
We were stuck for a few days trying to implement DayNight via AppCompat within our app. On API 24+ our Main activity, which hosts a ViewPager, was not being properly themed. We had inconsistent behavior on the inner fragments within the view pager hosting recycler views where they were either not themed for night mode or some items where partially getting themed. It was not until I found this issue that I was able to connect the dots as our ViewPage hosts a WebView within one of the fragments.
After adding the work around for the onCreate, we are now able to take advantage of this Support Lib feature but would like to know more about what is going on and what should we watch out moving forward. Specially as we have some devices already running Android O beta and the night theme for reasons unknown yet was not applied to some textviews.
further details are much appreciated.
ch...@google.com <ch...@google.com>
mn...@gmail.com <mn...@gmail.com> #8
Howdy, we can also confirm that the issue was fixed until we looked at O Preview where our tab bars are not applying night theme to the fonts. We can submit screenshots/apks if that helps.
ki...@google.com <ki...@google.com> #9
Alan - is this resource flushing that is bypassed on O?
al...@google.com <al...@google.com> #10
I am not sure, Chris will need to weigh in here.
al...@google.com <al...@google.com> #11
Mike, can you elaborate on "not applying night theme to the fonts"? Do you mean the actual font resources (ex. custom fonts as introduced in O) or just the textColor?
ki...@google.com <ki...@google.com> #12
Also - how does this look like under the latest released 25.3.1, as well as under 26.0.0 latest beta?
mn...@gmail.com <mn...@gmail.com> #13
The color is not being applied. So we would get background with black text. It works perfectly pre 0.
ki...@google.com <ki...@google.com> #14
What specific version of support library are you using?
mn...@gmail.com <mn...@gmail.com> #15
supportLibs : '25.3.1'
ki...@google.com <ki...@google.com> #16
Is this happening under beta1 of 26.0.0 as well?
mn...@gmail.com <mn...@gmail.com> #17
I can verify in am.
ch...@google.com <ch...@google.com> #18
@Kirill: If this is touching text color then it's not resource flushing, that was specifically for drawables. Look at my last comment in the blocked by bug, that's the cause for this.
mn...@gmail.com <mn...@gmail.com> #19
Our issue was resolved on our end.
ch...@google.com <ch...@google.com>
ki...@google.com <ki...@google.com>
[Deleted User] <[Deleted User]> #20
da...@gmail.com <da...@gmail.com> #21
#20 as you say, that's not good. Using `Application` as `WebView` context has other side effects, like `WebView` is unable to show dialogs (input date) and you need to develop workarounds...
ch...@google.com <ch...@google.com> #22
Just to ping this bug. We're still looking into this and MAY have a solution: https://android-review.googlesource.com/c/platform/frameworks/support/+/878200
No guarantees on whether this will land, since there's a lot of tricky stuff to handle here.
No guarantees on whether this will land, since there's a lot of tricky stuff to handle here.
ch...@google.com <ch...@google.com> #23
CL is in, and should be out in AppCompat 1.1.0-alpha03. Please test it!
xw...@gmail.com <xw...@gmail.com> #24
testing
ja...@gmail.com <ja...@gmail.com> #25
ch...@google.com <ch...@google.com> #26
Not yet, going out in ~2 weeks.
ja...@gmail.com <ja...@gmail.com> #27
Perfect, thanks!
ja...@gmail.com <ja...@gmail.com> #28
Seems to be working for me
ch...@google.com <ch...@google.com> #29
Awesome, closing this as AppCompat v1.1.0-alpha03 was released yesterday.
mi...@dailymotion.com <mi...@dailymotion.com> #30
Hi I'm using the appcompat 1.1.0, and I get this issue on a Pixel 3
Instantiating a WebView after setDefaultNightMode, revert to my default theme.
Putting WebView(this) before setDefaultNightMode is a (ugly) workaround for the moment.
Do you have some news about that ?
Thanks
Instantiating a WebView after setDefaultNightMode, revert to my default theme.
Putting WebView(this) before setDefaultNightMode is a (ugly) workaround for the moment.
Do you have some news about that ?
Thanks
ro...@gmail.com <ro...@gmail.com> #31
When will this be fixed? Still doesn't work with appcompat 1.2.0 alpha versions.
ga...@gmail.com <ga...@gmail.com> #32
When will this be fixed? Still doesn't work with appcompat 1.2.0 alpha versions.
xj...@gmail.com <xj...@gmail.com> #33
1.2.0-rc01 issue still here ...
[Deleted User] <[Deleted User]> #34
After about 2 years I come back this thread again. The issue still happens when I used native advance ads when using appcompat 1.2.0 and 1.3.0-apha01.
The only way to resolve this problem that still init a dummy WebView in Application before set night theme
The only way to resolve this problem that still init a dummy WebView in Application before set night theme
[Deleted User] <[Deleted User]> #35
1.2.0 issue still here ...
[Deleted User] <[Deleted User]> #36
Hey! You should try custom config workaround.
https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:appcompat/appcompat/src/androidTest/java/androidx/appcompat/testutils/BaseTestActivity.java;l=89-104?q=BaseTestActivity&ss=androidx%2Fplatform%2Fframeworks%2Fsupport
This is the suggestion.
https://www.reddit.com/r/androiddev/comments/idefss/were_on_the_engineering_team_for_android_jetpack/g3263de?utm_source=share&utm_medium=web2x&context=3
This is the suggestion.
ca...@seadowg.com <ca...@seadowg.com> #38
Still seeing this problem with appcompat 1.3.1. Constructing a dummy WebView
before forcing night mode acts as a workaround (as described earlier in this thread). This should be reopened I think.
sl...@pentacomp.pl <sl...@pentacomp.pl> #39
This issue is still present, using appcompat 1.4.0 here
ta...@gmail.com <ta...@gmail.com> #40
This issue is still present, using appcompat 1.6.0-rc01
ki...@google.com <ki...@google.com>
al...@google.com <al...@google.com>
dm...@gmail.com <dm...@gmail.com> #41
The issue is still present, using appcompat 1.5.1
da...@grupoasesores.com.mx <da...@grupoasesores.com.mx> #42
Still present nowdays... as a work around I've made this as suggested by ch...@google.com
protected void onCreate(Bundle savedInstanceState) {
if (Build.VERSION.SDK_INT >= 24) {
new WebView(this);
}
super.onCreate(savedInstanceState);
}
It's weird but it works.
FYI: I'm developing a multi fragment application with only one MainActivity, so I had to implement this one-time and that fixed the UiMode issue.
protected void onCreate(Bundle savedInstanceState) {
if (Build.VERSION.SDK_INT >= 24) {
new WebView(this);
}
super.onCreate(savedInstanceState);
}
It's weird but it works.
FYI: I'm developing a multi fragment application with only one MainActivity, so I had to implement this one-time and that fixed the UiMode issue.
pu...@gmail.com <pu...@gmail.com> #43
This is still an issue using Theme.Material3.DayNight from latest material-components-android, but only on Android 10 devices and below. This is particularly annoying when using AdMob. The ugly workaround to instantiate a WebView prior to calling AppCompatDelegate#setDefaultNightMode still work for these devices:
int nightMode = ...;
if (nightMode != AppCompatDelegate.MODE_NIGHT_NO && Build.VERSION.SDK_INT <= Build.VERSION_CODES.Q) {
try {
new WebView(getApplicationContext());
} catch (Exception ignored) {
}
}
AppCompatDelegate.setDefaultNightMode(nightMode);
ab...@gmail.com <ab...@gmail.com> #44
Still present, using androidx.appcompat:appcompat:1.7.0 and the hack "new WebView(this);" still works
Description
Version used: 25.0.0
Theme used: Theme.AppCompat.DayNight
Devices/Android versions reproduced on: Nexus 5x, Nexus 6 - Android 7.0
The activity containing a WebView is recreated (from onStart() method) because uiMode is changed when WebView is being created (inside its constructor). This only happens on the first WebView inflation.
Steps to reproduce this bug:
1º - Set the default night mode to AppCompatDelegate.MODE_NIGHT_YES on application class.
2º - Add a WebView to layout file (in the attached example a CustomWebView has been created only for logs purposes, common WebView has the same effect).
3º - Launch the app and the activity is recreated.
In appcompat-v7 versions previous to 24.2.0 the activity is not recreated but the uiMode is changed too.
Here some logs from:
Main: Before onCreate super() - Mode night active: false
Main: After onCreate super() - Mode night active: true
CustomWebView: Before constructor super() - Mode night active: true
CustomWebView: After constructor super() - Mode night active: false
Main: Before onCreate super() - Mode night active: false
Main: After onCreate super() - Mode night active: true
CustomWebView: Before constructor super() - Mode night active: true
CustomWebView: After constructor super() - Mode night active: true