@michaelmceuin: Thanks for the report!!

Could you please help us with a sample file where you're seeing this issue and if possible attach a screencast as well for triaging of the issue?

Thanks!!

Not really a simple issue...where we are seeing it is when do the following:

1. Go to https://www.defensetravel.osd.mil (Defense Travel System - DOD)
2. Loading this page, shows a page with a 'Log In' button.
3. Tap the 'Log in' button and follow the trace...it hits a JSP file and then redirects to another URL
4. In this case, 99% of the time, under Android 8.0/8.1, the 'shouldOverrideURLLoading()' is called, but 'shouldInterceptRequest()' is NOT called.
5. For us, that means (2) things
   a) We are not allowed to load the main HTML file and thus, can't go through our HTTP stack, which hooks our use of OpenSSL and our own middleware, for using CAC/PIV smart cards.
   b) Since we are not allowed to load the main HTML file, we also can't inject our Javascript, to capture Ajax and Forms data for submittal.

Essentially, our product, for some sites, is completely unusable because of this issue. Android 7.0 does not have this issue at all, that I can tell.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

michaelmceuin@ thanks for reporting this. It sounds like this may be related to multiprocess WebView. Could you answer a few more questions?

 1. What version of Chrome Stable do you have on your device?
   a. I assume you have not yet reconfigured webview implementation, otherwise tell me the version of that package
   b. Alternatively, you could launch your WebView to do a google search for "what's my user agent," which contains the version number
 2. Could you try using Chrome beta as a webview provider to let us know if this is fixed?
   a. Full instructions are here [1]
   b. Chrome beta contains a recent fix related to this, so there's a chance this has already been fixed

Also, do you think you could make a sample app which uses https://httpbin.org/ (see the "redirect/" options)? You could just put a Log.w() in the shouldInterceptRequest body. This would be a significant help with debugging.

[1] https://www.chromium.org/developers/androidwebview/android-webview-beta

@ntfschr Here are my answers, to the best of my knowledge.

1. We always keep our devices up to date. The device I'm testing on is a Pixel phone (original), running Chrome app version 65.0.3325.109.
  a. I don't know what you mean by 'reconfigured web view implementation'. We are building against android.webkit.WebView for API 26.
  b. When I check my User Agent, it shows Chrome v 61.0.3163.98.
2. I'll look through the instructions to see if we can run that test.
  b. That would be awesome. I will report back after testing

I will try the sample app thing as well and report back.

Thanks!

@michaelmceuin

@ntfschr Ok. I tried the 'Chrome Beta' (66.0.3359.82) from the Google Play store and switched my 'WebView Implemetation' to 'Chrome Beta' and tried again. I am now getting called EVERY time for 'shouldInterceptReqeust()', where before I was not.

So, it looks like your 'beta' fix has fixed our issue...awesome!

I did not try the sample app thing, but I assume it's not necessary now, since what was broke, is now fixed.

Do you have an ETA on when a 'stable' version is planned, with this fix included?

Thanks!

@michaelmceuin

> When I check my User Agent, it shows Chrome v 61.0.3163.98.

Hmm this should always match the relevant app version. For example, if your 'WebView Implementation' is Chrome beta, then WebView's user agent should have the same version number as the Chrome Beta package.

> So, it looks like your 'beta' fix has fixed our issue...awesome!

Good to hear! Yes, I recently fixed something related to the intersection of IoThread (which shouldInterceptRequest uses) and multiprocess (which affects Android O+). The canonical bug is  issue 818025 . I'll tentatively mark this as a duplicate, but please ping me if you see this come back.

> Do you have an ETA on when a 'stable' version is planned, with this fix included?

This will be in M66 stable. Please see https://www.chromium.org/developers/calendar