Issue metadata
Sign in to add a comment
|
No Cookie Request Headers in Cordova
Reported by
faisakh...@googlemail.com,
Dec 10 2017
|
||||||||||||||||||||||||||||||
Issue descriptionSteps to reproduce the problem: 1. This is a cordova application (using Cordova android 6.4.0) that includes an IFrame pointing to our website. The Webview has Third Party Cookies ENABLED. 2. Navigate within the IFrame and click on links found on the IFrame. 3. The next page loads in the IFrame but a new session cookies is created on each page request (No Request Header Cookies present). What is the expected behavior? Cookies should be present in the Request Header. What went wrong? Since the release of Chrome 63 on Android, on the 6th December 2017, I have encountered a problem with my companies Cordova based Android app. This app includes IFrames that allow users to navigate parts of my companies eCommerce website from within the app. The navigation between pages loaded in the IFrames no longer send any cookie information in the Request Headers. Information such as Session Ids that are stored in a cookie are not passed across to the next page, which in turn causes the next page to start a whole new user session! What is strange however is that any AJAX calls preformed within a page on the IFrames (e.g. To retrieve the number of items in the basket) and asset requests (css js, image files etc) do send cookie information in the request headers fine. The session id in these headers are identical between pages, indicating session persistence. Cookies are being created ok and I can see them when using the Chrome developer tools within the Application panel under the companies domain. They just aren't being passed to the next page. I experienced this issue on an Android 7.1.1 device. When I disable the Chrome app on this device the cookie request headers in the IFrames in the app begin to work fine again, presumably the Cordova Webview is no longer using Chrome when it is disabled? Does anyone know what may be causing this issue? Could it be anything related to SameSite cookies or Strict site isolation changes or other security related changes in Chrome 63? The issue appears similar to this Chromium bug that was fixed October 2016: https://bugs.chromium.org/p/chromium/issues/detail?id=634311 The Webview does have ThirdParty cookies enabled in the SystemCookieManager class of the Cordova library (Cordova Android 6.4.0): if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) { cookieManager.setAcceptThirdPartyCookies(webView, true); } Did this work before? Yes 62 Does this work in other browsers? N/A Chrome version: 63.0.3239.83 Channel: stable OS Version: 7.1.1 Flash Version:
,
Dec 11 2017
Same here. We have an ionic app, which makes use of an iframe for a ticket booking process. The App is issuing a session and retrieves a session key and also a session cookie via an api call to the website. when the same website is requested inside the iframe the cookie is not sent.
,
Dec 11 2017
We have the same issue within an native app using the webview. In the webview we display an iframe which shows a different site. However, within the iframe it seems to be that no cookies are stored!
,
Dec 11 2017
Can you please provide us with an apk for the ease of triaging this bug.
,
Dec 11 2017
,
Dec 12 2017
Thanks for reporting this! I can indeed reproduce this. This was another PlzNavigate related bug. I have attached a repro APK.
Using --disable-browser-side-navigation fixes the issue.
---
Steps to repro (with attached APK):
1. Open app
2. A page loads containing an iframe (via loadDataWithBaseUrl)
3. Look at the iframe, which should say `"cookies": {...}`
Expected results: the iframe page [1] successfully sets a cookie of the form:
"ican": "setcookies"
Observed results: the iframe sets no cookies
---
The relevant source code is:
```
final String cookiesUrl = "https://httpbin.org/cookies/set?ican=setcookies";
final String httpBinUrl = "https://httpbin.org/";
final String embedsIframeUrl = "<html><body><iframe src='" + cookiesUrl + "'></iframe></body></html>";
this.wv.loadDataWithBaseURL(httpBinUrl, embedsIframeUrl, null, null, null);
```
[1] https://httpbin.org/cookies/set?ican=setcookies
,
Dec 12 2017
Issue 793657 has been merged into this issue.
,
Dec 12 2017
,
Dec 12 2017
clamy@, can you or someone in your office investigate when you have a chance?
,
Dec 12 2017
Thank you for investigating the issue. Is the --disable-browser-side-navigation flag available for us to use within our android apps? If so an example of how to implement this would be very useful. What issues could it cause to use this flag?
,
Dec 12 2017
No, webview flags cannot be set by applications. They are intended for debugging only.
,
Dec 12 2017
So, we are out of luck until you manage to get a fix out, is that what you are saying? Do you do hotfixes or is it earliest Chrome 64 (January?) that fixes this? We need to have something to tell our not-so-pleased customers.
,
Dec 12 2017
The issue seems to be coming from https://cs.chromium.org/chromium/src/content/browser/frame_host/navigation_request.cc?dr&l=1040 This sets the site_for_cookie to a data_url (probably of the parent) that triggers a mismatch in https://cs.chromium.org/chromium/src/net/url_request/url_request_http_job.cc?dr=CSs&l=650
,
Dec 12 2017
The main issue is that we will stop supporting it very soon. We are looking into a fix to be deployed shortly. I don't recommend using the flag in the meantime as your app will break when we stop supporting it.
,
Dec 12 2017
clamy@: The main issue is that there's intentionally no way for an application to set command line flags for webview at all, specifically to stop apps from depending on flags we don't support.
,
Dec 12 2017
Update on this: the issue is in the computation of the URL for first party cookies. pre-PlzNavigate it is done in the renderer process, where it uses the base URL (from LoadDataWithBaseURL) - so https://httpbin.org in that case. With PlzNavigate the computation is done in the browser process, which believes that the URL of the top document is the data URL and not the base one. Still looking into why we have this discrepancy.
,
Dec 12 2017
Tested with an usage of base_url if it not empty here : https://cs.chromium.org/chromium/src/content/browser/frame_host/render_frame_host_impl.cc?q=render_frame_host_impl.cc&dr&l=1367 This fixes the issue. clamy@ is working on implementing a fix.
,
Dec 12 2017
cordova is a pretty big deal. we should respin with fix, if possible
,
Dec 12 2017
Assigning to clamy@ as per #18.
,
Dec 12 2017
I have a fix at https://chromium-review.googlesource.com/c/chromium/src/+/822572. We tested locally that the issue is fixed.
,
Dec 12 2017
> where it uses the base URL (from LoadDataWithBaseURL) I'm not 100% sure that this is *only* for loadDataWithBaseUrl... I just found that to be the easiest way to repro the bug. Fixing that is definitely a good start, but we need to confirm that this is not an issue on http(s):// pages containing other http(s):// pages as iframes.
,
Dec 12 2017
For me using loadUrl to load a http page with a http page as iframe (with same domain) is working. The issue appears only when loadDataWithBaseUrl is used.
,
Dec 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ce5b7e41cb45ca74c0b16aa572368e74a38975a6 commit ce5b7e41cb45ca74c0b16aa572368e74a38975a6 Author: clamy <clamy@chromium.org> Date: Tue Dec 12 21:39:06 2017 Android WebView: use base URL for cookies in the browser process This CL ensures that the base URL is properly used as the first_party_for_cookies URL in Android WebView if it is non-null. This fixes an issue with cookies being unproperly set for iframes if their parent was loaded through LoadDataWithBaseURL. BUG= 793648 Change-Id: I0f7da293f1e102f7b414ae799f701d48667eefc1 Reviewed-on: https://chromium-review.googlesource.com/822572 Commit-Queue: Camille Lamy <clamy@chromium.org> Reviewed-by: John Abd-El-Malek <jam@chromium.org> Cr-Commit-Position: refs/heads/master@{#523559} [modify] https://crrev.com/ce5b7e41cb45ca74c0b16aa572368e74a38975a6/content/browser/frame_host/navigation_request.cc
,
Dec 12 2017
from webview team, we were able to reproduce the issues on Nexus 6 / N2G47S AND Nexus 6P / NMF27E vs 63.0.3239.83 We will verify once the fix will be available
,
Dec 12 2017
> For me using loadUrl to load a http page with a http page as iframe (with same domain) is working. The issue appears only when loadDataWithBaseUrl is used. Thanks l3m3a3@, great news! --- Can external developers link us to their apps (either on play store, or attached compiled APK)? That would be very helpful to verify this is 100% fixed. Please provide test credentials if necessary. Thanks!
,
Dec 12 2017
alekyoo@ Would you mind providing the repro steps, triage team can help in verifying if the build is ready during IST timezone.
,
Dec 12 2017
,
Dec 12 2017
This bug requires manual review: Request affecting a post-stable build Please contact the milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), gkihumba@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 12 2017
,
Dec 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/87409ddc2bcae04748228c38f571096061284fbb commit 87409ddc2bcae04748228c38f571096061284fbb Author: clamy <clamy@chromium.org> Date: Tue Dec 12 23:50:20 2017 Android WebView: use base URL for cookies in the browser process This CL ensures that the base URL is properly used as the first_party_for_cookies URL in Android WebView if it is non-null. This fixes an issue with cookies being unproperly set for iframes if their parent was loaded through LoadDataWithBaseURL. BUG= 793648 Change-Id: I0f7da293f1e102f7b414ae799f701d48667eefc1 Reviewed-on: https://chromium-review.googlesource.com/822572 Commit-Queue: Camille Lamy <clamy@chromium.org> Reviewed-by: John Abd-El-Malek <jam@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#523559}(cherry picked from commit ce5b7e41cb45ca74c0b16aa572368e74a38975a6) Reviewed-on: https://chromium-review.googlesource.com/822463 Cr-Commit-Position: refs/branch-heads/3239@{#666} Cr-Branched-From: adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578} [modify] https://crrev.com/87409ddc2bcae04748228c38f571096061284fbb/content/browser/frame_host/navigation_request.cc
,
Dec 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/5cd18450034eec381fc1f4b5501b2f7c1a791638 commit 5cd18450034eec381fc1f4b5501b2f7c1a791638 Author: clamy <clamy@chromium.org> Date: Tue Dec 12 23:49:43 2017 Android WebView: use base URL for cookies in the browser process This CL ensures that the base URL is properly used as the first_party_for_cookies URL in Android WebView if it is non-null. This fixes an issue with cookies being unproperly set for iframes if their parent was loaded through LoadDataWithBaseURL. BUG= 793648 Change-Id: I0f7da293f1e102f7b414ae799f701d48667eefc1 Reviewed-on: https://chromium-review.googlesource.com/822572 Commit-Queue: Camille Lamy <clamy@chromium.org> Reviewed-by: John Abd-El-Malek <jam@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#523559}(cherry picked from commit ce5b7e41cb45ca74c0b16aa572368e74a38975a6) Reviewed-on: https://chromium-review.googlesource.com/822303 Cr-Commit-Position: refs/branch-heads/3282@{#188} Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840} [modify] https://crrev.com/5cd18450034eec381fc1f4b5501b2f7c1a791638/content/browser/frame_host/navigation_request.cc
,
Dec 13 2017
,
Dec 13 2017
,
Dec 13 2017
We have to tell our customers a time range when this fix will be released. Are there any plans? Could you please share that information with us?
,
Dec 13 2017
As a rule of thumb, we generally don't comment on release dates publicly. Note this has been merged to 63 and so users will get updated to it (i.e. don't need to wait until next major release). I highly encourage any developers that use WebView to use Chrome Beta as their system WebView. There are instructions at https://arstechnica.com/gadgets/2016/08/android-7-0-nougat-review-do-more-on-your-gigantic-smartphone/12/. This would alert us to these problems much earlier, and would prevent them from going out to stable releases.
,
Dec 13 2017
As requested, here is a link to one of our apps on the play store: https://play.google.com/store/apps/details?id=com.fghuk.kaleidoscope To reproduce the problem perform these steps: Open the app. From the home screen scroll down and click on Fashion. A product list page will load, from here click on any product. The product details page will slide in, select any product options combination (size/colour etc) and click on Add to bag. After the product has been added to the bag click on the bag tab to load the bag screen. With this issue present you will not see your product in the bag. If the issue has been resolved then the product will be found in the bag.
,
Dec 13 2017
Issue 793858 has been merged into this issue.
,
Dec 13 2017
Just as an FYI. As a temporary workaround. We have delivered a version of our application compiled with crosswalk ( https://crosswalk-project.org/) which was basically plug-and-play for us. Note however, the project is closed since February. https://crosswalk-project.org/blog/crosswalk-final-release.html
,
Dec 13 2017
Is this the same problem as being described in issue 793858 ?
,
Dec 13 2017
Using crosswalk now that it's abandoned means you are shipping a version of chromium which is 13 months out of date and has many critical and exploitable security issues.
,
Dec 13 2017
verified on Nexus 6P / NMF27E vs 63.0.3239.107
,
Dec 13 2017
re c#36 Developers can (and should) join WebView beta--which works on any device L and above! Instructions vary between L-M and N+, please see official docs here: https://www.chromium.org/developers/androidwebview/android-webview-beta. We also encourage dev & canary users (N+ only). As jam@ pointed out, this gives developers (you all) a chance to catch these regressions a full 6 weeks sooner, giving us time to fix them before users ever see them--it's a win-win-win situation.
,
Dec 14 2017
,
Dec 14 2017
tested motorola G4, android 6.0.1 IT IS NOT fixed vs 63.0.3239.107.
,
Dec 14 2017
tested Samsung S8+(SM-G955N), android 7.0 IT IS NOT fixed vs 63.0.3239.107.
,
Dec 14 2017
It is working fine in nexus6p with 63.0.3239.107 in browser. But for the app what we have, it is not working. Is it some specific change need to be done?
,
Dec 14 2017
The latest update to Chrome (63.0.3239.107) has NOT fixed the problem for our apps. Tested on a oneplus 5T Android 7.1.1
,
Dec 14 2017
We are affected by the same issue in multiple native app with webview containing a key iframe rather than Cordova. We can also confirm this is NOT fixed in 63.0.3239.107 on S8 or Oneplus5 devices tested on. We can provide reproduction steps but they require a verified customer account: if useful we can send via a private channel.
,
Dec 14 2017
Does the app in this example: https://stackoverflow.com/a/47767418/3337236 work for you with WebView 63.0.3239.107? It works for me. Samsung J5 (SM-J500H) with Android 6.0.1 I attach here the apk
,
Dec 14 2017
In my phone (Moto X Play) with System WebView 63.0.3239.107 and Chrome 62.xx I can confirm, that the test-webview.apk works now. Unfortunately our own Cordova app is still not working properly. You may reproduce by * installing https://play.google.com/store/apps/details?id=io.plan.app.cordova * on the fist screen enter "appdemo" and confirm * on the next screen you'll see a login form. Enter anything and confirm Instead of seeing a "Wrong password" error, I am seeing a "422 - Invalid form authenticity token." This is caused by the fact, that the iframe looses its cookies, so the CSRF protection doesn't work as expected.
,
Dec 14 2017
I am also seeing a "422 - Invalid form authenticity token." in Planio app. Also System WebView 63.0.3239.107 and Chrome 62.xx
,
Dec 14 2017
After the fix in comment #24 at https://chromium-review.googlesource.com/c/chromium/src/+/822572 The bug is fixed when I try the repro apk in comment #7 (Android 7.1.2) This change is included in the 63.0.3239.107 version. Maybe there is another bug or a different configuration that may explains why this bug seems not to be fixed for some people. I am trying to find a way to reproduce it.
,
Dec 14 2017
Thanks for the reports in comment #52 and #53! I can reproduce it.
,
Dec 14 2017
I made some logs: With browser-side-navigation: https://pastebin.com/raw/9wft3aGB With renderer-side-navigation: https://pastebin.com/aupqcsJp I look for request_->site_for_cookies(). In both case, I get: file:///android_asset/www/app.html It looks like there are no problems with site_for_cookie() this time. So I guess this is a different bug.
,
Dec 14 2017
The issue can be reproduced with a modified version of test-webview: https://www.dropbox.com/s/g79kodvduoe54kz/test-webview-2.zip?dl=0 The WebView is loaded this time with loadUrl instead of loadDataWithBaseUrl: String url = "file:///android_asset/html/main.html"; mWebView.loadUrl(url); I'm attaching the apk.
,
Dec 14 2017
The scenario is like this. Loading a specific url from app in iframe is having issues. On debug, we found that Cookies are available for the url. But its not sent along with request when we are trying to load the url in iframe
,
Dec 14 2017
The latest update to Chrome (63.0.3239.107) has NOT fixed the problem for our apps. Tested on a MOTO G4 Android 7.0
,
Dec 14 2017
> I look for request_->site_for_cookies(). In both case, I get: file:///android_asset/www/app.html Can you please log what is request_->site_for_cookies() for test-webview.apk in comment #51 and for test-webview-2.apk in comment #57? If they are different for these 2 apks, could be this the issue?
,
Dec 14 2017
Thank you for the second apk (comment 57), that's really appreciated! Update: Here are some new logs: browser-side-navigation: https://pastebin.com/raw/j0fKd4Q7 renderer-side-navigation: https://pastebin.com/raw/gyAsiUzm They are interesting. The difference is that in aw_cookie_access_policy in CanAccessCookies(), accept_third_party_cookies() return false instead of true. It cause the cookies not to be included in the HTTP request. I guess I am very close.
,
Dec 14 2017
The issue is in AwCookieAccessPolicy::GetShouldAcceptThirdPartyCookies() \o/ AwContentsIoThreadClient::FromID(render_process_id, render_frame_id) is used, but we don't have render_process_id and render_frame_id at this point. The AwContentsIoThreadClient::FromID(frame_tree_node_id) must be used instead. I have a working fix.
,
Dec 14 2017
I open the issue again for the second bug. First bug and second bug are not related. Here is the fix for the second one: https://chromium-review.googlesource.com/c/chromium/src/+/827018
,
Dec 14 2017
Please do not mix 2 bugs into one. If this one is fixed, close it and open a new one for the other bug.
,
Dec 14 2017
> Please do not mix 2 bugs into one. If this one is fixed, close it and open a new one for the other bug. Sorry about this. The fix is already in the CQ, so I can't prevent it to be referenced here in a few minutes. I can open a new bug after if necessary, but it's probably not desired.
,
Dec 14 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8c0b1dcaa85bbc72465d389981b46d4d0b86fcad commit 8c0b1dcaa85bbc72465d389981b46d4d0b86fcad Author: arthursonzogni <arthursonzogni@chromium.org> Date: Thu Dec 14 17:23:50 2017 Fix third party cookies not being sent in WebView iframes. The issue was in: AwCookieAccessPolicy::GetShouldAcceptThirdPartyCookies() AwContentsIoThreadClient::FromID(render_process_id, render_frame_id) was used, but at this point a navigation request is not associated with a renderer process yet. It caused the cookies not being sent with the request. The solution was to use AwContentsIoThreadClient::FromID(frame_tree_node_id) instead. Bug: 793648 , 794939 Change-Id: I5bda7affab67645cfd64c105b06c8a628047dd79 Reviewed-on: https://chromium-review.googlesource.com/827018 Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org> Reviewed-by: Richard Coles <torne@chromium.org> Cr-Commit-Position: refs/heads/master@{#524098} [modify] https://crrev.com/8c0b1dcaa85bbc72465d389981b46d4d0b86fcad/android_webview/browser/aw_cookie_access_policy.cc [modify] https://crrev.com/8c0b1dcaa85bbc72465d389981b46d4d0b86fcad/android_webview/browser/aw_cookie_access_policy.h
,
Dec 14 2017
Patch in comment 67 fixed the issue (verified locally). It is not merged though.
,
Dec 14 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0b1e6d69c9f2f03ff07a1cf0df694d36dc35faf3 commit 0b1e6d69c9f2f03ff07a1cf0df694d36dc35faf3 Author: arthursonzogni <arthursonzogni@chromium.org> Date: Thu Dec 14 19:30:33 2017 Fix third party cookies not being sent in WebView iframes. The issue was in: AwCookieAccessPolicy::GetShouldAcceptThirdPartyCookies() AwContentsIoThreadClient::FromID(render_process_id, render_frame_id) was used, but at this point a navigation request is not associated with a renderer process yet. It caused the cookies not being sent with the request. The solution was to use AwContentsIoThreadClient::FromID(frame_tree_node_id) instead. Bug: 793648 , 794939 Change-Id: I5bda7affab67645cfd64c105b06c8a628047dd79 Reviewed-on: https://chromium-review.googlesource.com/827018 Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org> Reviewed-by: Richard Coles <torne@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#524098}(cherry picked from commit 8c0b1dcaa85bbc72465d389981b46d4d0b86fcad) Reviewed-on: https://chromium-review.googlesource.com/827565 Reviewed-by: John Abd-El-Malek <jam@chromium.org> Cr-Commit-Position: refs/branch-heads/3239@{#678} Cr-Branched-From: adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578} [modify] https://crrev.com/0b1e6d69c9f2f03ff07a1cf0df694d36dc35faf3/android_webview/browser/aw_cookie_access_policy.cc [modify] https://crrev.com/0b1e6d69c9f2f03ff07a1cf0df694d36dc35faf3/android_webview/browser/aw_cookie_access_policy.h
,
Dec 14 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/584a409e8edac71cdc9b80a043648e08d68e0618 commit 584a409e8edac71cdc9b80a043648e08d68e0618 Author: arthursonzogni <arthursonzogni@chromium.org> Date: Thu Dec 14 19:31:28 2017 Fix third party cookies not being sent in WebView iframes. The issue was in: AwCookieAccessPolicy::GetShouldAcceptThirdPartyCookies() AwContentsIoThreadClient::FromID(render_process_id, render_frame_id) was used, but at this point a navigation request is not associated with a renderer process yet. It caused the cookies not being sent with the request. The solution was to use AwContentsIoThreadClient::FromID(frame_tree_node_id) instead. Bug: 793648 , 794939 Change-Id: I5bda7affab67645cfd64c105b06c8a628047dd79 Reviewed-on: https://chromium-review.googlesource.com/827018 Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org> Reviewed-by: Richard Coles <torne@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#524098}(cherry picked from commit 8c0b1dcaa85bbc72465d389981b46d4d0b86fcad) Reviewed-on: https://chromium-review.googlesource.com/827567 Reviewed-by: John Abd-El-Malek <jam@chromium.org> Cr-Commit-Position: refs/branch-heads/3282@{#231} Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840} [modify] https://crrev.com/584a409e8edac71cdc9b80a043648e08d68e0618/android_webview/browser/aw_cookie_access_policy.cc [modify] https://crrev.com/584a409e8edac71cdc9b80a043648e08d68e0618/android_webview/browser/aw_cookie_access_policy.h
,
Dec 15 2017
Verified. I'm no longer able to reproduce the issue on: Nexus 6P / NMF27E vs 63.0.3239.111 Tested on Planio App from "comment 52". Before I used to see "422 - Invalid form authenticity token." now just "invalid user or password" when entering wrong credentials.
,
Dec 15 2017
I took at look at comment #37 (app is region-locked to United Kingdom (code "GB")). I confirm that 63.0.3239.111 also fixes for that app, following the steps provided in that comment.
,
Dec 15 2017
Cool. Issue related to iframe is resolved for our app. Thanks guys
,
Dec 15 2017
Great, seems that the cookies bug introduces in in V63 is resolved now. Thanks
,
Dec 15 2017
I can also confirm that this latest Chrome update has resolved the issues for our apps too (same as comment #73). Thank you.
,
Dec 15 2017
Fix issue verified on latest M63: 63.0.3239.111 steps as per # 52 Tested device:Pixel / OPR3.170623.013
,
Dec 15 2017
I can also confirm that version 63.0.3239.111 resolves our issues.
,
Dec 18 2017
Updating to 63.0.3239.111 resolves our problem! Thanks!
,
Dec 18 2017
Marking as verified as per #74 -#79.
,
Dec 19 2017
The same issue is identified. Chrome beta version 64.0.3282.29 google play release date 18.12.2017
,
Dec 19 2017
Unfortunately, this fix did not make the cut for 64.0.3282.29. It should be in the next M64 beta.
,
Jan 2 2018
Would you please confirm when the fix will be merged into the next Chrome Beta M64 release available on Play Store? The Chrome Beta version currently on Play Store is still 64.0.3282.29. Thank you.
,
Jan 2 2018
Verified the fix on latest M64.0.3282.67 on Pixel 2XL/OPM1.171019.018 and fix will will be in the upcoming M64 beta shortly. |
|||||||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||||||
Comment 1 by tobias.m...@tieto.com
, Dec 11 2017