Note: I have to add a workaround for this in the 63.0 version of the app which should get released in about 1.5 weeks.
You can probably get the 62.x version from various archives or from the Play store.  If not, please let me know and I can email you a copy of the older 62.x APK to repro the issue.

Tested the issue on android and unable to reproduce this issue, no crash is seen

Steps to reproduce:
--------------------------
1. Launched Gmail, clicked on link -- opened in kayak app 
2. Now selected kiwi.com, clicked on view, scrolled to bottom, selected airport transit visa link and no crash is seen

Webview version:
68.0.3440.91

OS:
Android 9.0 

Android device:
Pixel 2  

@ kyee: Please check the above steps/screencast and let us know if we miss anything. Is this issue consistently reproducible? Any information on reproducing the issue would help in better triaging.

Thanks!

Deleted: 20180821_144804.mp4 12.3 MB

	20180821_144804.mp4 12.3 MB View Download

At 39 seconds into your video, you saw the crash.  Android restarted the app automatically because it couldn't grab the exception which is happening inside the binaries for Chrome webview.  Do "adb logcat" just before you click on that link.
What should happen is it should open up a web page on the kiwi.com website.  Instead, it restarted the app automatically and brought you back to the screen just before the webview.

Easily reproducible on Android 8.0 (Galaxy Note 8 and emulator) as well, but Android prompts with the "app crashed...open again" dialog.

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

symbolize_microdump.py on chromepopupcrash.txt gives:

Thread 0 (crashed)
 0  libmonochrome.so!content::NavigationControllerImpl::DiscardPendingEntry(bool) [navigation_controller_impl.cc : 1857 + 0x1]
    eip = 0x99bdf9bc   esp = 0xbffc5150   ebp = 0xbffc51b0   ebx = 0x9d005154
    esi = 0xada8d73c   edi = 0xbffc51d8   eax = 0xada8d700   ecx = 0x9ce36db4
    edx = 0x00000000   efl = 0x00000246
    Found by: given as instruction pointer in context

but it only gives the one frame, which is suspicious.

The link in the original report is broken. I tried a different flight but I don't see "Fugerhage" or any hand icons on the "Kiwi.com" page.

chelamcherla@, since you have a repro, can you try reproing again and posting the complete logcat here?

Paul: FYI, it's any webview popup on that page that causes this.  E.g., clicking on the link in the screenshot w/ the 62.x version of our app will cause the crash as well (the app store version is 63.2 which has my workaround already).

Deleted: Screen Shot 2018-09-07 at 9.58.32 AM.png 76.0 KB

	Screen Shot 2018-09-07 at 9.58.32 AM.png 76.0 KB View Download

I mean the "kiwi guarantee" link in green two thirds of the way down the screen

As per c#6 tried reproducing the issue on Pixel2/Android 9 but now not seeing airport transit visa link as mentioned in C#3. Attaching screenshots for reference.

kyee@:Please check the screenshot and let us know how to proceed further.

Thanks!

Deleted: Screenshot_20180910-182105.png 141 KB

	Screenshot_20180910-182105.png 141 KB View Download

I found the link in the original report to be broken. Try opening the app and picking a different flight.

Also, if you're using the current version of the kayak app, I already worked around it.
You need version 62.x or below.  You should have this on your test phone unless you're autoupdating.

Crash handling on x86 unfortunately works a bit differently to ARM and we don't test it or use it anywhere near as often (x86 devices are a pretty small % of the population in the wild and we don't get a lot of issues from the emulator).

If it repros on a real device that's probably the easiest way, but it may be worth a bit of probing to see if there's actually something wrong with breakpad on x86 here or if this crash is just "unlucky" and can't be unwound for other reasons.

As per comment#10 and #11, we do not have prev version of Kayak app(i.e; 62.0), We have only 63.2 version which is available now in playstore.

On using kayak 63.2 issue is not seen, no app restart is seen.

Assigning back to Paulmiller@, please feel free to un-assign.

Thanks! 

I did warn that you had to keep A62 on your phones for testing ;-)

Anyways...I attached the APK to this ticket.  If you still have problems repro'ing, let me know.  It should be a 2min repro :-P

Deleted: KAYAK-kayakFree-release-62.0-1239.apk 19.5 MB

KAYAK-kayakFree-release-62.0-1239.apk 19.5 MB Download

Tested the issue in Android and able to reproduce the issue, app closes on clicking More Info link

Steps to reproduce:
--------------------------
1. Launched Gmail, clicked on link https://www.kayak.com/flights/BOS-MOW/2018-12-06/2018-12-10-flexible-2days/f662d6ca7298fbe09bd8fc4d990a8c777/1adults/children-11-11-11-11 -- opened in kayak app 
2. Now selected kiwi.com, clicked on view, scrolled to bottom, didn't see any airport transit visa link 
3. Hence clicked on More info link and "Kayak has stopped" popup is seen and app gets restarted.

Webview version:
64.0.3240.0 , 69.0.3497.100 , 71.0.3555.0

OS:
Android 8.0 

Android device:
Pixel 2  

NOTE: Tried bisecting and below are the observations.
1. On base webview version i.e; 61.0.3163.98 issue is not seen i.e; on clicking more info it successfully navigated.
2. On installing Monochrome dev builds from M-61 to M-63 we are not seeing change of webview option in webview Implementation under developer options
3. Issue is seen on installing Monochrome dev build from M-64 starting version 64.0.3240.0.

As issue is seen from M-64 considering this issue as Non-Regression.

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

Thanks!

I took a quick look. I don't think this has *anything* to do with gmail. Here's some easier repro steps:

1. Install the kayak APK which kyee@kayak.com attached above.
2. Open kayak app. Our team can sign in via Google acct (webviewteam@gmail.com)
3. Search for flights (pick locations, times, passengers, etc.). I don't think you need any magic values here, probably any search query will work.
4. Click on a flight in the search results (again, I think pretty much any flight will work)
5. Look for "kiwi.com" at the top. Click the orange "View" button
6. Scroll a small bit. Look for "Kiwi.com Guarantee". Click the green "More info" button (this is demonstrated in the video at go/chrome-androidlogs/876000)
7. Observe a crash.

The microdump in the logcat looks like https://paste.googleplex.com/5626880900202496 (internal link only, sorry). It looks a bit like [1], except that link has a frame between DiscardPendingEntry and LoadURLWithParams.

---

I can repro in a local build. We're hitting this CHECK [2]. In particular, the issue is in_navigate_to_pending_entry_ == true and IsBeingDestroyed() is false.

CC'ing authors of recent changes to this file: any ideas why WebView might hit this?

---

kyee@kayak.com thank you for an excellent bug report. If possible, could you explain what your app is doing at this point in the code, with respect to WebView? Are you overriding any WebView callbacks (especially: are you calling any WebView APIs from within those callbacks)? If you can paste java code, that would help even more.

[1] https://crash.corp.google.com/browse?q=stable_signature%3D%27content%3A%3ANavigationControllerImpl%3A%3ADiscardPendingEntry-927a6789%27
[2] https://cs.chromium.org/chromium/src/content/browser/frame_host/navigation_controller_impl.cc?l=1794&rcl=337471139a22264cf842b0555117ca70627b9660

Not sure why you'd think it has anything to do w/ gmail :-)
It's clearly a quirk w/ the Chromium webview on Android since that's that's needed to repro.

As for what the app is doing, the use case is handling popup windows inside a webview on Android.  The popups can have fields that are filled in and you can't really implement them as "back button" behavior where the previous HTML page is reloaded which is bad UX (that's my current workaround because bad UX is better than crashing out all the time).  So what we do is overlay webviews on top of each other in a FrameLayout.  The "popup" acts more like a real popup in a full web browser.

Every webview has callbacks hooked up as you'd expect.  We hook in WebChromeClient and WebViewClient because we need all the callbacks to deal w/ the popups and loading progress.

Can't post our code unfortunately...legal wouldn't like that :-(

> Not sure why you'd think it has anything to do w/ gmail :-)

Gmail uses webview. Your original repro mentioned gmail drafts; this could either mean it's due to complex interaction with the WebView in gmail, or this could just be an extraneous step. Not wrong to include it, but that's why I mention it's extraneous info.

> The popups can have fields that are filled in and you can't really implement them as "back button" behavior where the previous HTML page is reloaded which is bad UX

I can't find any flights with the kiwi link today. Can you share some trick to search for those flights?

ahh...I just suggested using a gmail draft to launch a deeplink...thought it'd be easier on the QA testers than asking them to run an adb command :-)

Look for Kiwi flights a bit further out...a lot of stuff disappears if you're looking for a booking in the next few days.  
Same BOS->MOW search in the first week of January works for me.  Go to the filters, turn off Hacker Fares under Quality and then go to the Booking Sites filter and turn on Kiwi.com and you should get them.

Filtering by booking sites works like a charm (thanks for the tip).

Now that I can repro again, I see you're calling loadUrl+extraheaders from the shouldOverrideUrlLoading callback. This caused a huge headache at  issue 794020 . We added some regression tests for that issue, but I guess we didn't test the popup case (which is very tricky in WebView). So, that seems like the likely culprit (there's no crash if WebView chooses to ignore the callback).

I'll try to write up a test case for WebView.

Yep...we have to add a Referer header when doing the fake "popup webview" or some of the providers' popups wouldn't load properly.  Code looks like this for that method:
@Override
        public boolean shouldOverrideUrlLoading(WebView view, String url) {
            if (!loadingFinished) {
                redirect = true;
            }
            loadingFinished = false;

            String previousUrl = view.getUrl();

            if (previousUrl != null && !previousUrl.startsWith("https:") || !url.startsWith("http:")) {
                Map<String, String> headers = new HashMap<>();
                headers.put("Referer", previousUrl);

                view.loadUrl(url, headers);
            }
            else {
                view.loadUrl(url);
            }

            return true;
        }

You should never call loadUrl(url); like that - that just restarts the same exact navigation for no reason. You should simply return false if you don't want to override the URL load.

It also looks like the logic you are implementing there is... just the standard browser logic for whether to include a referer header? It's not clear why you would have to do that at all unless I'm missing something :)

You might find your app works exactly the same if you just remove that entire function. I have no idea if that will actually resolve this bug or not, though.

The Referer header was needed because the webview didn't send it (which seemed odd to me too)...might have been because of the non-chromeview webviews in older versions of Android...it's a very odd if too...only adds the Referer header if the previous URL wasn't a standard http/s one.  Not sure why it was added and the linked ticket to that change didn't mention anything either.  It's one of those weird bits of code where you wonder if it should be removed but might have some weird legacy implication :-(

Good point about the view.loadUrl() being a waste of time.  I'll make that return false.  Thanks.

Looks like the crash is happening from using loadUrl w/ the headers.  If I remove all that and return false, the crash in chromium is gone.  Hopefully, that'll help you w/ your unit test :-)

If the old version of the code was also doing view.loadUrl(url) that may actually be *why* it wasn't sending it - if you start a new navigation like that, then that may not send Referer. It's a very common mistake for apps to implement shouldOverrideUrlLoading as just "view.loadUrl(url); return true;" and then be surprised when not everything works "normally".

It's not "if the previous URL wasn't a standard http/s one", it's actually the standard browser algorithm for referrers: don't send it when going https->http to avoid the URL of the previous secure page being transmitted in the clear, but do in other cases.

I suspect that you won't actually break anything if you just remove the whole function, as a result, and if that fixes the crash for you then that solves your problem ;)

As for fixing the crash: this looks like just a different form of  issue 794020  as Nate says.

> You should simply return false if you don't want to override the URL load.

Torne is right. But, for the sake of posterity, here's a link to our recent docs change explaining this [1].

> I suspect that you won't actually break anything if you just remove the whole function

kyee@ can you try removing the shouldOverrideUrlLoading override and report back if it works as intended (at least for L+ devices)?

[1] https://developer.android.com/reference/android/webkit/WebViewClient.html#shouldOverrideUrlLoading(android.webkit.WebView,%20android.webkit.WebResourceRequest)

Yep, definitely works as intended if I remove all the view.loadUrl calls and that entire if segment from that method.
It looks like that's the right thing to do.  Thanks for looking into it.  Now I can get rid of the other workaround I had.

Would still be a good idea not to have the chromeview crash if developers do the wrong thing :-)

Yes, we'll keep this open to fix the crash. I've also filed issue 889537 to propose that we detect this common API misuse and warn developers about it.

We have all the feedback we need, it's just a matter of fixing the crash.

I created a minimal repro that doesn't depend on the kayak app.

Deleted: WebViewTest.zip 129 KB

WebViewTest.zip 129 KB Download