The Surrogate opens a tab, so the launch runs in a fresh __about_~_blank__ document with no user activation. Expect the modal, and with the fix expect it to stay until Allow/Deny.
Expect a direct launch, no modal, before and after the fix.
This is the case Ji asked about. Two possible paths depending on what the Surrogate reports as the new tab's URL:
(a) reports about:blank → client loads __about_~_blank__, then an update_navbar carries the mailto → assignOrReplace → gated, hold acquired, modal shown. Covered by the fix.
(b) reports the mailto directly → tab.js navigates the popup with Util.locationReplace → no gate, no hold, no modal. Not covered.
Both buttons are the same JS shape, only the scheme differs, so any difference between them comes purely from the scheme check on the Surrogate side. Compare what each one does and whether the popup logs the deferred-close line below.
These stay in this tab, so no tab close is pending and the modal survives with or without the fix. Here to confirm no regression.
These also reproduce in prepend mode, unlike mailto:.
Enable "Auto-open DevTools for popups" and "Preserve log" first, otherwise the popup takes its console with it when it closes.
Gated path (covered): the popup logs
Deferring tab close; 1 modal hold(s) outstanding
and the modal stays.
Ungated path (not covered): no such log line, no modal, and the popup either launches the app straight away or closes doing nothing.
Also check the popup's URL. __about_~_blank__ means path
(a); anything else means the Surrogate reported the applink directly.