Assigned
Status Update
No update yet.
Comments
nt...@google.com
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.
nt...@google.com
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.]
nt...@google.com
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:
mi...@gmail.com
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
jo...@gmail.com
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
Component used: WebView Version used: 103.0.5060.71, code: 506007137 Devices/Android versions reproduced on:
Project, where bug can be reproduced:
First commit - default project AS template without any changes
Second commit - added WebView. pinch-to-zoom works
Third commit - added
android:windowEnableSplitTouchflag with valuefalse. pinch-to-zoom works buggyBug has been reproduced only at android 13. Versions below works good.
Desription:
There is flag in theme
android:windowEnableSplitTouchthat affects multitouch in WebView component. When default value are used or flag set astruemultitouch works app-wide. When value set tofalsemultitouch disabling in whole app except WebView.In attached project (last commit) pinch-to-zoom works only when I drag from right side with some distance from screen center. Pinch-to-zoom doesn't work when I try to drag from left side of screen or if I drag from right side of screen with small distance. Video attached. Video recorded from emulator, so, unfortunately it is unclear, how i am dragging, so i describe below.
At first i place cursor at right side of screen and then drag to center. I do this few times. Graph is zooming. Then i place cursor closer to center of screen also at left side and drag to center too. Graph is not zooming. Then i place cursor at right side of screen and also drag to center. Graph is not zooming.
I see same behavior only at android 13, but only on few devices. For example I can't reproduce that on my real Pixel 6 Pro. On other android versions all works correct.
So the question: should multitouch works in WebView, when it disabled globally? I think it should. And if it should, so described above is a bug. If shouldn't - so there is feature request: could you please add possibility to enable multitouch in WebView separately from app?