Assigned
Status Update
Comments
di...@google.com <di...@google.com>
ji...@google.com <ji...@google.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.
th...@google.com <th...@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.]
di...@google.com <di...@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:
di...@google.com <di...@google.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
di...@google.com <di...@google.com> #6
Project: chromium/src
Branch: main
Author: Adam Walls <
Link:
[WV] Determine if partitioned cookies are not sent to apps.
Expand for full commit details
[WV] Determine if partitioned cookies are not sent to apps.
This allows an investigation into how often partitioned cookies are not
passed to apps. Using CookieManager::SiteHasCookieInOtherPartition, this
indicates whether a site's cookies, with one partition key, also has the
same cookies with a different cookie partition key. This will prove that
there are cookies being omitted on a given site due to the partitioning.
Co-Authors: bewise, avvall
Bug: 41496912
Change-Id: I3698788038afc16c23bb05f6e7f485394433fd07
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6237015
Reviewed-by: Peter Beverloo <peter@chromium.org>
Reviewed-by: Elly FJ <ellyjones@chromium.org>
Reviewed-by: Maks Orlovich <morlovich@chromium.org>
Commit-Queue: Adam Walls <avvall@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1417004}
Files:
- M
android_webview/browser/aw_feature_map.cc
- M
android_webview/browser/cookie_manager.cc
- M
android_webview/browser/cookie_manager.h
- M
android_webview/common/aw_features.cc
- M
android_webview/common/aw_features.h
- M
android_webview/java/src/org/chromium/android_webview/common/ProductionSupportedFlagList.java
- M
android_webview/javatests/src/org/chromium/android_webview/test/CookieManagerTest.java
- M
services/network/cookie_manager.cc
- M
services/network/cookie_manager.h
- M
services/network/public/mojom/cookie_manager.mojom
- M
services/network/test/test_cookie_manager.h
- M
tools/metrics/histograms/metadata/android/histograms.xml
Hash: cbebd148e6898552bdd91af1c63c92b2de40beed
Date: Thu Feb 06 13:52:04 2025
Description
Version used: 1.4.0-alpha01
Devices/Android versions reproduced on: Any
androidx.window.embedding.EmbeddingAnimationParams can Not be found.