Assigned
Status Update
Comments
oh...@gmail.com <oh...@gmail.com> #2
To work around this for our CHIPS tests, we had to use a java bridge and report what was available in javascript. But this doesn't fully cover http cookies which is an issue.
https://crrev.com/c/5250507
We should fix this when we implement this CookieManager API.
We should fix this when we implement this CookieManager API.
ak...@google.com <ak...@google.com> #3
This issue was migrated from crbug.com/chromium/1523964?no_tracker_redirect=1
[Monorail components added to Component Tags custom field.]
[Monorail components added to Component Tags custom field.]
jj...@google.com <jj...@google.com>
ti...@google.com <ti...@google.com> #4
Another issue is that shouldInterceptRequest does not include the cookie header which forces developers to query it at the time of requests. We should include this as well.
Because this will likely require a breaking change, I will first experiment with this behind a flag:
oh...@gmail.com <oh...@gmail.com> #5
Project: chromium/src
Branch: main
commit 041b6a3c262e0ee8656e42fa6aa9cf32362fa9f2
Author: Rupert Ben Wiser <bewise@chromium.org>
Date: Fri Jun 28 18:08:13 2024
webview: Add cookie headers to shouldInterceptRequest
The problem is that shouldInterceptRequest
gets fired before the net stack ultimately adds the
cookie header. This means that Android developers have to
separately query the cookie manager for headers but as we introduce
new changes to the cookie header, the CookieManager API
can't keep up.
The one issue with this approach is that we are of course
having to try replicate what the network stack would be doing.
In this case, I am matching the partitioning but there
could be other cookie behaviors we need to preserve.
We are somewhat forced to maintain this already for WebView's
restricted cookie manager so we can share the policy which lowers
the maintenance burden a bit.
We also discovered that Set-Cookie doesn't have an effect with
shouldInterceptRequest either for similar reasons.
The Set-Cookie header is not allowed to be persisted over the mojo
calls so we need to return that value to our URL Loader factory with a
simple callback.
Bug: 41496912
Change-Id: Iff5cc37ab0f678c59503cc9d69e3c05cd4ccdf4a
Reviewed-on:https://chromium-review.googlesource.com/c/chromium/src/+/5616051
Reviewed-by: Richard (Torne) Coles <torne@chromium.org>
Commit-Queue: Rupert Wiser <bewise@chromium.org>
Auto-Submit: Rupert Wiser <bewise@chromium.org>
Reviewed-by: Mike Taylor <miketaylr@chromium.org>
Reviewed-by: Dylan Cutler <dylancutler@google.com>
Cr-Commit-Position: refs/heads/main@{#1321072}
M android_webview/browser/aw_content_browser_client.cc
M android_webview/browser/aw_cookie_access_policy.h
M android_webview/browser/network_service/aw_proxying_url_loader_factory.cc
M android_webview/browser/network_service/aw_proxying_url_loader_factory.h
M android_webview/common/aw_switches.cc
M android_webview/common/aw_switches.h
M android_webview/java/src/org/chromium/android_webview/common/ProductionSupportedFlagList.java
M android_webview/javatests/src/org/chromium/android_webview/test/AwContentsClientShouldInterceptRequestTest.java
M android_webview/javatests/src/org/chromium/android_webview/test/CookieManagerTest.java
M components/embedder_support/android/util/android_stream_reader_url_loader.cc
M components/embedder_support/android/util/android_stream_reader_url_loader.h
https://chromium-review.googlesource.com/5616051
Branch: main
commit 041b6a3c262e0ee8656e42fa6aa9cf32362fa9f2
Author: Rupert Ben Wiser <bewise@chromium.org>
Date: Fri Jun 28 18:08:13 2024
webview: Add cookie headers to shouldInterceptRequest
The problem is that shouldInterceptRequest
gets fired before the net stack ultimately adds the
cookie header. This means that Android developers have to
separately query the cookie manager for headers but as we introduce
new changes to the cookie header, the CookieManager API
can't keep up.
The one issue with this approach is that we are of course
having to try replicate what the network stack would be doing.
In this case, I am matching the partitioning but there
could be other cookie behaviors we need to preserve.
We are somewhat forced to maintain this already for WebView's
restricted cookie manager so we can share the policy which lowers
the maintenance burden a bit.
We also discovered that Set-Cookie doesn't have an effect with
shouldInterceptRequest either for similar reasons.
The Set-Cookie header is not allowed to be persisted over the mojo
calls so we need to return that value to our URL Loader factory with a
simple callback.
Bug: 41496912
Change-Id: Iff5cc37ab0f678c59503cc9d69e3c05cd4ccdf4a
Reviewed-on:
Reviewed-by: Richard (Torne) Coles <torne@chromium.org>
Commit-Queue: Rupert Wiser <bewise@chromium.org>
Auto-Submit: Rupert Wiser <bewise@chromium.org>
Reviewed-by: Mike Taylor <miketaylr@chromium.org>
Reviewed-by: Dylan Cutler <dylancutler@google.com>
Cr-Commit-Position: refs/heads/main@{#1321072}
M android_webview/browser/aw_content_browser_client.cc
M android_webview/browser/aw_cookie_access_policy.h
M android_webview/browser/network_service/aw_proxying_url_loader_factory.cc
M android_webview/browser/network_service/aw_proxying_url_loader_factory.h
M android_webview/common/aw_switches.cc
M android_webview/common/aw_switches.h
M android_webview/java/src/org/chromium/android_webview/common/ProductionSupportedFlagList.java
M android_webview/javatests/src/org/chromium/android_webview/test/AwContentsClientShouldInterceptRequestTest.java
M android_webview/javatests/src/org/chromium/android_webview/test/CookieManagerTest.java
M components/embedder_support/android/util/android_stream_reader_url_loader.cc
M components/embedder_support/android/util/android_stream_reader_url_loader.h
Description
Pixel 7 Pro/Android 13
I've encountered a behavior inconsistency on my Pixel 7 Pro when using WindowInsetsControllerCompat to adjust the behavior of system bars. It seems there's a conflict between systemBarsBehavior and setDecorFitsSystemWindows.
I utilized the following code to customize my window behavior:
'''
WindowInsetsControllerCompat(window, window.decorView).apply {
hide(WindowInsetsCompat.Type.systemBars())
systemBarsBehavior = WindowInsetsControllerCompat.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE
}
WindowCompat.setDecorFitsSystemWindows(window, false)
'''
After setting the systemBarsBehavior, it seems to override or conflict with the behavior of setDecorFitsSystemWindows. Even when delaying the application of setDecorFitsSystemWindows, its behavior doesn't manifest as expected.
Interestingly, the setDecorFitsSystemWindows setting only seems to work when systemBarsBehavior is set to WindowInsetsControllerCompat.BEHAVIOR_DEFAULT. This then allows for the expected behavior when swiping from the edge to bring up the system bars.
Additional Information:
This peculiar behavior is not replicated on an Android 13 emulator, which leads me to believe it may be specific to the Pixel 7 Pro or its particular Android version.
Hoping this issue can be investigated and addressed accordingly. Many thanks in advance!
full code for test
'''
@Composable
fun FullScreenTest() {
val window = (LocalContext.current as Activity).window
var boxSize by remember { mutableStateOf(IntSize.Zero) }
Box(
modifier = Modifier
.fillMaxSize()
.background(Color.LightGray)
.onGloballyPositioned { coordinates ->
val newSize = coordinates.size
if (boxSize != newSize) {
boxSize = newSize
}
}
) {
Column(
verticalArrangement = Arrangement.spacedBy(16.dp),
modifier = Modifier.padding(16.dp)
) {
Bar.values().forEach {
ElevatedButton(onClick = {
WindowInsetsControllerCompat(window, window.decorView).apply {
systemBarsBehavior = it.behavior
}
WindowCompat.setDecorFitsSystemWindows(window, false)
}) {
Text(text = it.text)
}
}
}
Text(
text = "Size = $boxSize", fontSize = 20.sp, modifier = Modifier
.align(Alignment.BottomCenter)
.padding(16.dp)
)
ElevatedButton(onClick = {
WindowInsetsControllerCompat(
window,
window.decorView
).hide(WindowInsetsCompat.Type.systemBars()) },
modifier = Modifier.align(Alignment.BottomCenter).padding(vertical = 50.dp)) {
Text("hide system bar")
}
}
LaunchedEffect(Unit) {
WindowInsetsControllerCompat(window, window.decorView).apply {
hide(WindowInsetsCompat.Type.systemBars())
systemBarsBehavior = WindowInsetsControllerCompat.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE
}
WindowCompat.setDecorFitsSystemWindows(window, false)
}
}
enum class Bar(val behavior: Int, val text: String) {
BEHAVIOR_DEFAULT_NO_FITS_SYSTEM_WINDOWS(
WindowInsetsControllerCompat.BEHAVIOR_DEFAULT,
"behavior default"
),
BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE_NO_FITS_SYSTEM_WINDOWS(
WindowInsetsControllerCompat.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE,
"behavior show transient bars by swipe"
)
}
'''