inamdar.mohamadazhar@ -- Thanks for reporting this issue. Could you please share a sample application or APK file to test this issue and verify good and bad behavior at Chrome TE's end along with the device details on which the issue is observed.

You can also verify by updating your WebView to #66.0.3359.158 and let us know your observations.

Thanks in advance!

1. I had already shared a full working example here https://github.com/zenith22/ContentDemo 

2. The same issue exists on latest Android System Webview v66.0.3359.158.

3. Device Details 
-Motorola Moto G (3rd gen)
-Android Lollipop 5.1.1

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

Note: this was originally filed as http://b/79232671 (I've closed the buganizer issue).

inamdar.mohamadazhar@ -- As requested in Comment #2, please share the APK file. That would help us in reproducing and triaging at TE's end easily.

pnangunoori@ and ntfschr@ :-

Please find attached the sample apk, also I have shared the code on github repository here https://github.com/zenith22/ContentDemo.

Deleted: app-release.apk 585 KB

app-release.apk 585 KB Download

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

I tried 54.0.2840.85 and 53.0.2785.124. I see no visible difference in application behavior.

inamdar.mohamadazhar@ please upload a screen recording (video) with both versions of WebView. You should demonstrate the correct behavior on M53 and the broken behavior on M54 (or any version which is broken). Please indicate the full version numbers you try for each video. This will be a big help to our investigation.

Steps for screen recording: https://developer.android.com/studio/command-line/adb#screenrecord

---

I believe we have a CTS test to cover this exact case (WebViewClientTest#testShouldOverrideUrlLoadingOnCreateWindow). However, this test has been disabled chromium-side [1]. That's linked to  issue 659077  (filed because of flakiness).

[1] https://cs.chromium.org/chromium/src/android_webview/tools/cts_config/expected_failure_on_bot.json?l=28&rcl=13f8c33d9a153f6788732be298b1635cec81a207

Took a closer look at the CTS test. I don't think it currently verifies we call shouldOverrideUrlLoading from onCreateWindow (that functionality would be verified by the commented-out section).

Team members can reference http://b/12804986 - we've had this bug open forever, and have never successfully fixed this.

pnangunoori@ and ntfschr@ :-

-Please find attached the mp4 files with appropriate names as AndroidSystemWebview versions. 
-As you can see in 53_0_2785_124.mp4 tapping on Local pdf file link invokes shouldOverrideUrlLoading() with proper url (file:///storage/emulated/0/Sample/samplepdf.pdf)
-In 54_0_2840_85.mp4 shows that tapping on Local pdf file link does nothing.
-Also I have shared the code on github repository here https://github.com/zenith22/ContentDemo 


Note: With both Webview versions the second link(HTTPS pdf file link) shown in demo works fine.

Deleted: 53_0_2785_124.mp4 6.4 MB

	53_0_2785_124.mp4 6.4 MB View Download

Deleted: 54_0_2840_85.mp4 5.5 MB

	54_0_2840_85.mp4 5.5 MB View Download

Tested the issue in Android and able to reproduce the issue. 

Steps Followed:
1. Install the APK file provided in the comment #7.
2. Tap on the link - Local pdf file link
3. Observed that shouldOverrideUrlLoading() callback of the WebviewClient inside OnCreateWindow() does not get triggered.

Chrome versions tested:
54.0.2791.0, 66.0.3359.158(Stable), 68.0.3432.0(Canary)

Devices:
Pixel 2 /Android 8.1.0 and Micromax A106/ Android 5.0.0

Using the per-revision bisect providing the bisect results,
Good Build - 54.0.2804.0
Bad Build - 54.0.2808.0 
(2805, 2806, 2807 - builds not available) 

Please navigate to below link for log's and video--
go/chrome-androidlogs/842645

As we are unable to provide per revision bisect Untriaging this issue.

Thanks!

Ah, I can repro on the attached compiled APK (your github repo and compiled APK differ--that threw me off!).

I've also confirmed the bisect in comment #12 (range can be narrowed to 54.0.2804.0..54.0.2806.0). Only 2 CLs touch android_webview/ in that range, nothing suspicious. Probably a content layer change.

ntfschr@chromium.org

Earlier when I had shared the apk the codebase was same as the compiled apk.
The codebase is different now since I had to make changes to demo it in a better for the videos. Not sure what went wrong.

Anyways, please ould you let me know when will this be fixed? Any timelines?

It is a critical regression for me.

re comment#16 this regressed quite a while ago, and I'm not sure if WebView team every got this fully working (see my comment#10).

Our team will certainly investigate this, but I don't think this is a trivial fix--I cannot promise any timeline.

Not critical, but it would help a tiny bit if you could upload your local changes for Toasts to your github repo.

re comment#17

The latest changes I made for the videos attached, are all available on my github repo. 

Please understand, this issue is having a huge impact on my apps functionality, its really critical for me and moreover a regression. 
Request you to get this fixed.

Also Would really appreciate if you could provide me with a workaround meanwhile.  

Can you please provide an update. 

Bisected to https://codereview.chromium.org/2166113002

That was awhile ago..

So the way I understand it..

Change in render_frame_impl.cc applies to this case. After that change, clicking on a file:// url will cause it to fall into the "should_fork" code path, with the intent that browser side will handle the load, which has the opportunity to swap to a different renderer process.

Before that change, it just fall down to the "normal" load code path, which on trunk with plznavigate is the kWebNavigationPolicyHandledByClient branch, which is also handled by browser side.

I guess something must have dropped the should_fork OpenURL request, but only in the webview popup code path. Things appear to work correctly if I remove target="_blank". Hmm...

Here's a one-line fix with a description of the bug: https://chromium-review.googlesource.com/c/chromium/src/+/1089386

Gonna run through tests, and get opinion of a content owner.

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

commit 300c6052043f60782f89a471135218ac5cfb340f
Author: Bo Liu <boliu@chromium.org>
Date: Tue Jun 12 04:46:07 2018

Save OpenURLParams if null delegate

A delegate can be null when a pop up WebContentsImpl is first created.
During this time, loads are supposed to be suspended before a delegate
is set. However the flow for loading file:/// url (and other loads) as
well ends up doing a browser side navigation (WebContentsImpl::OpenURL)
instead of WebContentsImpl::CreateNewWindow. The bug in this case is
that the OpenURL call is simply dropped. Fix by setting
delayed_open_url_params_ which is the existing mechanism for resuming
suspended loads for pop ups.

Bug:  842645 
Change-Id: Ibbe3088534ccd66f3c2803800e9a51bc51f5e485
Reviewed-on: https://chromium-review.googlesource.com/1089386
Commit-Queue: Bo <boliu@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#566315}
[modify] https://crrev.com/300c6052043f60782f89a471135218ac5cfb340f/content/browser/web_contents/web_contents_impl.cc
[modify] https://crrev.com/300c6052043f60782f89a471135218ac5cfb340f/content/browser/web_contents/web_contents_impl_browsertest.cc
[modify] https://crrev.com/300c6052043f60782f89a471135218ac5cfb340f/content/public/test/content_browser_test.cc
[modify] https://crrev.com/300c6052043f60782f89a471135218ac5cfb340f/content/public/test/content_browser_test.h
[modify] https://crrev.com/300c6052043f60782f89a471135218ac5cfb340f/content/shell/browser/shell.cc
[modify] https://crrev.com/300c6052043f60782f89a471135218ac5cfb340f/content/shell/browser/shell.h
[modify] https://crrev.com/300c6052043f60782f89a471135218ac5cfb340f/content/test/data/simple_links.html

Fix landed in M69. I don't think we need to cherry-pick to M68.

verified the fixed on Device: Samsung S5/L on webview : 69.0.3473.0, Will let the bug filer to check and verify the fix when M69 is available.