Fix browser test goroutine leak on cleanup

[ankur22]

What?

Fixes a goroutine leak when running the browser tests. Emit an Exit event on the Global event system during test cleanup, which triggers handleExitEvent -> unsubscribe -> channel close, allowing both goroutines to exit cleanly.

Why?

The browser registry spawns handleIterEvents and handleExitEvent goroutines per VU, which block on channel receives. These channels are only closed when an Exit event is emitted, but the test VU never emitted one. This caused goroutines to leak across tests, accumulating hundreds of stuck goroutines and eventually causing the browser test suite to exceed its timeout.

This should:

1. help run the browser tests a tiny bit faster, and help avoid CI failures such as https://github.com/grafana/k6/actions/runs/21440300997/job/61741331170
2. reduce the number of goroutine leaks

Goroutine leak comparison (800s timeout)

Goroutine	Before fix	After fix
browserRegistry.handleIterEvents	679	1 (active test)
browserRegistry.handleExitEvent	679	1 (active test)
BaseEventEmitter.syncAll	32	28
Browser.initEvents	4	4
Connection.sendLoop	4	4
Connection.handleIOError	3	3
BrowserProcess.handleClose	4	4
NetworkManager.handleEvents	4	4
Total leaked browser goroutines	1409	49

The 679 leaked handleIterEvents/handleExitEvent goroutine pairs (one per newTestBrowser call) are completely eliminated. The remaining single instance of each is from the actively running test at timeout. The remaining 47 goroutines are from a separate leak in tests that create browser connections without closing them (addressed in a follow-up PR).

Checklist

• I have performed a self-review of my code.
• I have commented on my code, particularly in hard-to-understand areas.
• I have added tests for my changes.
• I have run linter and tests locally (make check) and all pass.

AI tool usage

• Claude
• Cursor
• Codex
• Other
• I acknowledge that I fully understand the code change

Checklist: Documentation (only for k6 maintainers and if relevant)

Please do not merge this PR until the following items are filled out.

• I have added the correct milestone and labels to the PR.
• I have updated the release notes: link
• I have updated or added an issue to the k6-documentation: grafana/k6-docs#NUMBER if applicable
• I have updated or added an issue to the TypeScript definitions: grafana/k6-DefinitelyTyped#NUMBER if applicable

Related PR(s)/Issue(s)

[codebien]

I didn't review yet in detail. But I assume this line means wait indefinitely. Can we have a time-limited context so it will time out at some point? or alternatively tb.Context()

[ankur22]

Yeah, good spot. If you follow the code path to what the exit event does it will eventually call this. From there it looks like it's pretty straight forward local executions (no IO or long running tasks), i guess there's potential to some sync contention though when trying to close the tracer, but apart form that it doesn't look computationally heavy.

What i'm trying to get at is that I don't think we need a timeout, and if something does go wrong and we're waiting indefinitely then it might be better to surface it?

If you have a strong opinion then i can change it to a context with timeout with 5 seconds.

[codebien]

we're waiting indefinitely then it might be better to surface it?

I changed my mind, I agree with it 🤝