Thanks for reporting! This is already fixed in newer builds.

However, you may want to consider moving away from using custom URL schemes. They aren't well supported by the web security model and while we're attempting to preserve backward compatibility in webview there is a nonzero risk of other regressions in future. HTTPS origins using a domain that the app owns/controls are the best choice even if all the content is provided via shouldInterceptRequest.

Thanks for that. We will look into moving away from the custom schema at some point. Any idea on what the schedule is for pushing the fix?

Already released to stable, will be released in the next beta push which are roughly weekly.

Can anyone confirm that this is actually fixed? I'm still seeing the problem in my WebView apps using Chrome Beta 71.0.3578.31, which should have the fix according to the changelog (https://chromium.googlesource.com/chromium/src/+log/71.0.3578.20..71.0.3578.31?pretty=fuller&n=10000).

We are also still seeing the issue, with 71.0.3578.45

Thanks for flagging that; I'll investigate further here. A couple of questions:

1) Could one of you provide a sample application that reproduces this issue?

2) Did you have this issue on 70, or was it first broken in 71?

1) https://play.google.com/store/apps/details?id=com.blackberry.hub (also requires https://play.google.com/store/apps/details?id=com.blackberry.infrastructure)

To reproduce the problem, compose a new email message and save it as a draft. Then edit the draft, changing just the email body. During editing, tap the Back arrow and notice that the changes to the draft are lost (if using Chrome 71). That doesn't happen with Chrome 70.

2) We first noticed this with Chrome Beta 71.0.3578.31. The issue doesn't happen with the production version of Chrome 70.

We can work around the issue as described in Comment 1, but I expect that a fair number of other apps will break.

We have only seen the issue in 71, 70 has been fine. Did you want a copy of our app, or sourcecode to replicate the issue? 

There are two modules implementing CORS; ThreadableLoader and ResourceLoader. XHR is covered by ThreadableLoader and the one I fixed for issue 898589 was the latter. So it's possible that XHR still has the problem.

That said, I haven't found any suspicious changes so far.

Re #7: You should definitely move away from using custom protocols when you can. We've recently had a lot of discussion about different ways of loading content in the light of bugs like this and it seems like this is both hard to consistently support in the web platform and not actually necessary for any application use cases (it's always possible to just use a real origin instead, on all existing WebView/Android versions). We're looking at how to guide apps toward better patterns with support library assistance/documentation/etc, but you should assume that using nonstandard URLs is at risk of being deprecated once we're confident that it's clear what apps should be doing instead. Using real URLs is not a workaround, but the right way to do it in the first place.

A minimal test app with sourcecode would be ideal to track this down, but the repro instructions for blackberry in #7 might be enough. Test team: would you be able to bisect where this broke using that process or is it too fiddly?

Actually, no need for a bisect, because it seems like this 
is broken by the same change as issue 896059: https://chromium-review.googlesource.com/c/chromium/src/+/1208811

Unknown URL schemes have an opaque origin after this change, so a request from one foo:// URL to another is now cross-origin and would require CORS (which only works for web schemes).

The other bug is unfortunately not public but I'm working with the code owners there to come up with a solution.

Able to repro the issue mentioned on comment #7 on Blackberry Priv/MMB29M on the app Blackberry hub /1.6.1.15188 on 71.0.3578.55 where edit changes on draft gets lost but issue not reproduced in 70.0.3538.80(stable version ).

We are planning to replace our custom protocol within the next couple weeks.

Sorry, I'm being chased a lot from above over the risk of this going out. Is this going to make it in before the beta goes live, or is there a possibility that the issue will make it out to users before the fix?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/73b9579dda0c94c358e412b26cfb1d38d8dbd82c

commit 73b9579dda0c94c358e412b26cfb1d38d8dbd82c
Author: Changwan Ryu <changwan@google.com>
Date: Mon Nov 19 23:14:52 2018

Add tests for XHR across custom-schemed URIs

When you use custom-schemed URLs across XHR, you will see an error
saying that you cannot send an XHR from 'null' origin. This CL adds
tests to compare the behavior between HTTP-schemed URL and
custom-schemed URL such that the actual fix can pick it up.

Bug: 898589,  900528 , 896059
Change-Id: I43b4748a6595298d4ac6fdb216c8db1738719adf
Reviewed-on: https://chromium-review.googlesource.com/c/1340999
Reviewed-by: Richard Coles <torne@chromium.org>
Commit-Queue: Changwan Ryu <changwan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#609490}
[modify] https://crrev.com/73b9579dda0c94c358e412b26cfb1d38d8dbd82c/android_webview/javatests/src/org/chromium/android_webview/test/LoadDataWithBaseUrlTest.java

We're blocking our stable release on this issue as you can see from the labels, but users using beta webviews are already broken.

Handing this over to changwan@ who is adding the test case for this and will verify once the fix for the root cause lands.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/743e405a230b9b70f5ec5f9ccfeec45f35e6fd17

commit 743e405a230b9b70f5ec5f9ccfeec45f35e6fd17
Author: Nate Fischer <ntfschr@chromium.org>
Date: Wed Nov 21 00:32:27 2018

AW: add test to network service filter

No change to production logic.

This adds a newly added test to the network service test filter:
LoadDataWithBaseUrlTest#testXhrForHttpSchemeUrl. This was added during
http://crrev/c/1340999.

R=jam@chromium.org

Bug: 898589,  900528 , 896059
Test: CQ
Change-Id: I6e83bc3da5389c27761cf2c80620c8990bb6a850
Cq-Include-Trybots: master.tryserver.chromium.android:android_mojo
Reviewed-on: https://chromium-review.googlesource.com/c/1345246
Reviewed-by: Clark DuVall <cduvall@chromium.org>
Commit-Queue: Nate Fischer <ntfschr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#609866}
[modify] https://crrev.com/743e405a230b9b70f5ec5f9ccfeec45f35e6fd17/testing/buildbot/filters/mojo.fyi.network_webview_instrumentation_test_apk.filter

Is there anything needed for stable here? This is marked as a release blocker for 71 stable.

Issue 896059 seems to have fixed this issue. Closing.

Hi There, we are still seeing this issue with 71.0.3578.75. I will start working on a example app of our scenario, to provide in case I had missed something from the report that was affecting our experience. 

Has issue 896059 been fixed in 71.0.3578.75?

A patch has landed in 72.0.3625.0: https://chromium-review.googlesource.com/c/1338660

We're trying to merge it to M71.

When will 72.0.3625 be available to test?

Thanks.

Sorry again, when will a release of 71 have the fix, be available?

Thanks.

Chrome Canary is not updated yet, but once it has the right version,
you can test it by setting 'webview implementation' to Chrome Canary in developer options.

If you need this more urgently, you can build your own webview:
https://www.chromium.org/developers/how-tos/build-instructions-android-webview

But this might be too much of a hassle.

Hi, we have just tried Chrome Canary 72.0.3625.2 and it has fixed our issue. 

Can we please have confirmation that the fix it will be put into 71 before release?

Thanks.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/dd548ee4bc979f76190bb74d7818a5d29a9fcd8f

commit dd548ee4bc979f76190bb74d7818a5d29a9fcd8f
Author: Changwan Ryu <changwan@google.com>
Date: Fri Nov 30 22:31:03 2018

//url: Allow Android WebView to use origins with non-standard schemes

This adds an escape hatch so that Android WebView can restore the old
behavior before https://crrev.com/c/1208811/.

Bug: 896059
Change-Id: I90cc51fe5c6ddaa95281a51a5b89795e8a3958fe
Reviewed-on: https://chromium-review.googlesource.com/c/1338660
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Changwan Ryu <changwan@chromium.org>
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#611436}
(cherry picked from commit c2b752b1d03355b2e9bbde897731b616e9f70883)

Add tests for XHR across custom-schemed URIs

When you use custom-schemed URLs across XHR, you will see an error
saying that you cannot send an XHR from 'null' origin. This CL adds
tests to compare the behavior between HTTP-schemed URL and
custom-schemed URL such that the actual fix can pick it up.

Bug: 898589,  900528 , 896059
Change-Id: I43b4748a6595298d4ac6fdb216c8db1738719adf
Reviewed-on: https://chromium-review.googlesource.com/c/1340999
Reviewed-by: Richard Coles <torne@chromium.org>
Commit-Queue: Changwan Ryu <changwan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#609490}
(cherry picked from commit 73b9579dda0c94c358e412b26cfb1d38d8dbd82c)

Add a test for window.origin

Check window.origin value for HTTPS-schemed base Uri vs
custom-schemed base Uri.

(cherry picked from commit 54ef219a7191071dd74382ab6a9668ebd76be81c)

Bug: 896059
Change-Id: Ic310c584e0826d14683734f8e6190875dddcc28f
Reviewed-on: https://chromium-review.googlesource.com/c/1340821
Reviewed-by: Bo <boliu@chromium.org>
Commit-Queue: Changwan Ryu <changwan@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#608887}
Reviewed-on: https://chromium-review.googlesource.com/c/1357559
Reviewed-by: Changwan Ryu <changwan@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#863}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}
[modify] https://crrev.com/dd548ee4bc979f76190bb74d7818a5d29a9fcd8f/android_webview/common/aw_content_client.cc
[modify] https://crrev.com/dd548ee4bc979f76190bb74d7818a5d29a9fcd8f/android_webview/javatests/src/org/chromium/android_webview/test/LoadDataWithBaseUrlTest.java
[modify] https://crrev.com/dd548ee4bc979f76190bb74d7818a5d29a9fcd8f/content/common/url_schemes.cc
[modify] https://crrev.com/dd548ee4bc979f76190bb74d7818a5d29a9fcd8f/content/public/common/content_client.h
[modify] https://crrev.com/dd548ee4bc979f76190bb74d7818a5d29a9fcd8f/third_party/blink/renderer/platform/weborigin/security_origin.cc
[modify] https://crrev.com/dd548ee4bc979f76190bb74d7818a5d29a9fcd8f/third_party/blink/renderer/platform/weborigin/security_origin_test.cc
[modify] https://crrev.com/dd548ee4bc979f76190bb74d7818a5d29a9fcd8f/url/origin.cc
[modify] https://crrev.com/dd548ee4bc979f76190bb74d7818a5d29a9fcd8f/url/origin_unittest.cc
[modify] https://crrev.com/dd548ee4bc979f76190bb74d7818a5d29a9fcd8f/url/scheme_host_port.cc
[modify] https://crrev.com/dd548ee4bc979f76190bb74d7818a5d29a9fcd8f/url/url_util.cc
[modify] https://crrev.com/dd548ee4bc979f76190bb74d7818a5d29a9fcd8f/url/url_util.h

Can you please confirm that the above commits, mean that this issue has been fixed in the upcoming release of Chrome 71?

I can confirm that 71 will have the same fix as 72 that you've tested.

Thank you very much for confirming.