BYOND Version:515.1630 and 515.361
Operating System:Windows 10 Pro 64-bit
Web Browser:Firefox 123.0
Applies to:Dream Seeker
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:
Since version 15.1630 and still present in 15.1631, there has been a lot more lingering dreamseeker processes when playing SS13, which affects performance.

When once you'd have to check for these every now and again, now each round played seems to spawn 4 of these.
Numbered Steps to Reproduce Problem:
1. Join a /tg/ SS13 server
2. Notice performance decline.
3. Close the program.
4. Open Task manager.
5. Find the culprits.
Code Snippet (if applicable) to Reproduce Problem:

Expected Results:
None, or little lingering processes. Game performance only being affected on consecutive games.
Actual Results:
Common performance loss when compared to 15.1627
Does the problem occur:
Every time? Or how often?
In other games?
In other user accounts?
On other computers?

When does the problem NOT occur? When staying in lobby instead of playing.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit to download old versions for testing.)

There's nothing I can investigate here. Joining a remote server to test isn't really an option and doesn't help me get to the bottom of any issues. I'm not even certain this is fully a BYOND problem or if it's at least partly caused by something in /tg. (That is to say, Dream Seeker not shutting down properly is certainly a BYOND bug, but there may be something specific, perhaps even recently changed, in /tg's codebase that might be triggering this. For instance, TGUI is pretty extensive, and it also touches the browser.)

It doesn't seem logical that this issue started in 515.1630, since there have been no significant changes to any of the usual culprits typical of shutdown problems, and none to any code governing how shutdowns are handled. Considering 1630 was close on the heels of two other releases, I'd recommend trying 1628 and 1629 at least to see if the issue persists there. It would be helpful to at least narrow down what version this started in.

Ultimately I'll probably need a proper test case to investigate this issue. If other /tg users are having a problem then perhaps this is something that the maintainers can work up a test for.
In response to Lummox JR
Actually I couldn't check 15.1628/15.1629 because they are missing from here:
and I can't find a different source.
The issues is still present in 15.1632 unfortunately
This isn't the game window hanging around, it's newly spawned windows being created by byond://winget calls from javascript due to a bug in byond that keeps it from catching those sometimes. (seems to be mostly from closing the window)

Basically the handler for those fails to catch them, and then ie treats them as normal protocol links, and launches byond to handle a ?winget url.

you can reproduce it by running dreamseeker with a winget url:

"C:\Program Files (x86)\BYOND\bin\dreamseeker.exe" byond://winget

Ideally it would show a window and print an error message or it would just exit, instead it hangs around.

Based on how they can sometimes impact performance despite using almost no cpu, i suspect the processes are starting up far enough to initialize the gpu.

The solution Lummox is just to make dreamseeker detect this startup argument and just exit.
I have a bug report that's been up since 2015, but it's hidden for security reasons. The only way I've managed to "fix" it, is to stop the user from closing windows that have any kind of timeout, interval, or requestanimationframe work going on, and invalidating the content by sending an empty file prior to closing the window.

Unfortunately, there's really no good way to do this for popup windows, and detecting every browser that could cause this issue to make preventing this problem trivial is kind of a nightmare.

In some instances, a single Dreamseeker process can balloon into 30+ processes which will never abide the user's attempts to close them without using taskkill in powershell.

I'm hopeful that this is resolved with webview2.
it doesn't need webview2 nor is it as unfixable as lummox thinks.

fix it from the other angle, make the ds process not hang around when launched with that param.
Nearly certain this is fixed. Thank you!