To be clear, the attacker could have just sent you directly to the other page containing malware first. He shows the alert() prompt first only in the hopes of better tricking the reader into doing something unsafe on the upcoming the malicious page.

So the potential feature request here is "Allow the browser to dismiss a modal dialog AND block further script execution at the same time."

Yes, thank you for clarifying. I agree. 

Definitely not something we'd usually track as a vulnerability, but leaving it open in case anyone from Security UX thinks there's work to do here.

This is a duplicate of another bug which was recently fixed. Thanks!

This is actually different from  Issue 263326 .  That bug is for when pages are showing alerts in a loop, which prevented the user from being able to close the Tab and continue browsing.

The solution here of stopping JavaScript execution for a malicious ad is not feasible on iOS, as WKWebView does not expose API to stop a specific frame; only the entire web view.  Issue 674649 was created to track non-modal JavaScript dialogs, which will allow the user to close a Tab without having to interact with the JavaScript dialog, but this requires a bit of refactoring and cross-team communication, so will take some time to implement.  As elawrence pointed out though, if a malicious ad is already capable of displaying a JavaScript alert, interacting with the alert does not give the ad any extra permissions or information.