Worker.terminate() aborts the currently running script evaluation, see https://html.spec.whatwg.org/multipage/workers.html#dom-worker-terminate-dev https://html

Worker.terminate() aborts the currently running script evaluation, see https://html.spec.whatwg.org/multipage/workers.html#dom-worker-terminate-dev https://html.spec.whatwg.org/multipage/workers.html#dom-work... → https://html.spec.whatwg.org/multipage/workers.html#terminate-a-worker https://html.spec.whatwg.org/multipage/workers.html#terminat... → https://html.spec.whatwg.org/multipage/webappapis.html#abort-a-running-script https://html.spec.whatwg.org/multipage/webappapis.html#abort..., but that’s a fairly fuzzy definition, and it’s not generally reasonable to expect that to interrupt a currently executing piece of native code, because interrupting that (e.g. by sending a signal to the thread and forcibly starting unwinding) could leave data structures in a memory-unsafe state (that is, in the improbable worst case this could be a vector for escaping the sandbox). It’s possible they’ve come up with some way of working around this, but it’s going to be considerably easier and safer to just treat native code as uninterruptible by default, and possibly get known-slow blocking operations to manually periodically check if they’re being asked to stop. So I say my gut feeling is that the match operation won’t actually be interrupted, and I wouldn’t be inclined to depend on it actually being interrupted without explicit documentation of what aborting does, even if all environments I cared about did abort it immediately.