ID:2240271
 
BYOND Version:511
Operating System:Windows 10 Pro 64-bit
Web Browser:Safari 10.1
Applies to:Dream Seeker
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:
Setting an on-close handler on a browser popup using winset doesn't take effect immediately if the window id has not yet been seen by the client, even in the case of calling winset after browse. winget reports it not being set and the verb is never run. This appears to be recent, possibly as of 511. As a workaround, putting the winset call inside of a short spawn() appears to fix it (seems to be racing the client, if the window id hasn't yet been seen at least once, the winset is dropped and an error message about an unknown window ID appears in the messages window).

Numbered Steps to Reproduce Problem:
1. Open a window using usr << browse(content, "window=abc")
2. Use winset(usr, "abc", 'on-close="some-verb some-arg"')
3. Observe some-verb not being called, winget reporting no on-close

Code Snippet (if applicable) to Reproduce Problem:
usr << browse("", 'window="abc"')
winset(usr, "abc", 'on-close="some-verb some-arg"')


Expected Results:
winset called after browse should work. The client should store these until the window appears, or serialize until pending window operations have completed.

Actual Results:
Windows open without proper settings, specifically in this case, on-close.

Does the problem occur:
Every time? Or how often?
Reliably, every time. Once the window id has been seen, it works as expected.
In other games?
Haven't tested outside of SS13, but pretty basic feature.
In other user accounts?
Yes.
On other computers?
Yes.

When does the problem NOT occur?
When the window ID has already been seen.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
I believe it worked properly in 510, but have not tested extensively.

Workarounds:
Wrap winset calls in a short spawn()
I suspect this is not new to 511. More likely, the issue simply became more noticeable in 511. I can see how this kind of thing would happen.
This has been a known issue at /tg/ for awhile, this is our solution:

https://github.com/tgstation/tgstation/blob/master/code/ datums/browser.dm#L106

(this code traces back to December 2015)