Doing some more digging on this and it seems the issue is specific to using alert or confirm in the handler. But I'm still not sure why there's a difference in how it works on iphone vs ipad.

It appears that doing a setTimeout than an alert or confirm works just fine.

I am seeing this issue for Canary Version 71.0.3577.0 (Official Build) canary (64-bit)

It looks like from your repro steps you're talking about iOS, but the OS version is a Mac OS.  Can you update with the iOS version and iPad type that you're using?

Sorry about that! I have the issue using a retina iPad mini on iOS 11.2.6. We've had reports from customers of this happening on iOS 11 and 12, but I'm not sure which model iPad they're using.

Probably a duplicate of  bug 893951  - but only if it's seen in Chrome 71, not in 69.

I've reproduced this bug in 68 and 69 on iPad.

Thank you for the bugreport. John do you have a test page to reproduce this issue?

#8 - the report above mentions this -
> This JS Bin shows the problem https://jsbin.com/xetitejuku/edit

Thanks for the test page. Lindsay, can we ask test team to bisect this?

Tested on iPad Pro 12'9 iOS 11.4.1

GOOD BUILD - 67.0.3396.127 last beta.ipa in storage.
https://drive.google.com/file/d/1MdU1yhgYTs6q85_eDVUwp3n3jk8x-kki/view?usp=sharing

BAD BUILD -  68.0.3397.0 Canary.ipa
https://drive.google.com/file/d/1DhPx5ikNE4YLr_hHGHV6Egralxupxae3/view?usp=sharing

Do we have M67 Canary to check where the regression happened on trunk?

67.0.3396.127 Canary.ipa is a Good Build.

Thanks. Would you mind updating this bug with good and bad revisions.

Revision for the good build 
https://drive.google.com/file/d/1liqKniPu-qvdF6ECC0EM1A2ymn9J7W4f/view?usp=sharing

Revision for the not so good build 
https://drive.google.com/file/d/1ZBf7SZWIJexmBDg5KsqlG8EgQp7s-7Bp/view?usp=sharing

To clarify previous comments: 
Good Version: 67.0.3396.127 #74b8f33
Bad Version:  68.0.3397.0   #dcddf51

Bug is NOT reproduced on any of the M67 builds and reproduced on all of the M68 builds. M68.0.3397.0 is the first available canary version.

Thanks! Revision 74b8f33 was landed on Jul 20 and points to the branch. 

Good Revision: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038 
Bad Revision: dcddf51ec4ce5a464f901c1cf8fc8cc86c9f59b6

Same here on Windows, too.

Google Chrome	71.0.3573.0 (Offizieller Build) dev (64-Bit) (cohort: Dev)
Überarbeitung	540477605ecd461a31985e4fcd67e8786e895802-refs/branch-heads/3573@{#1}
Betriebssystem	Windows
JavaScript	V8 7.1.281

This has regressed here: https://chromium-review.googlesource.com/981684
This CL introduces a new view controller to the hierarchy, which I think just exposes the problem which actually existed before.

When following the steps in debug mode, I see the following DCHECK in tryToPresent:
DCHECK(!self.showingDialog);

Kurt, can you take a look why we DCHECK?

#19 - Windows and iOS are completely separate and different (iOS uses WebKit under the hood, Windows uses Blink) in this regard. Please, create a new issue for what you are seeing.

The windows problem is fixed in new 71.0.3578.10 (Offizieller Build) dev (64-Bit)