ID:2902296
 
BYOND Version:514
Operating System:Linux
Web Browser:N/A
Applies to:Dream Seeker
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:

Numbered Steps to Reproduce Problem:
* Use a BYOND App with overlaid Browser/Output skin controls such as most /tg/ derived SS13 codebases. I can only confirm the issue on CM-SS13 codebase.
* Output control is set as default and visible in skin while Browser is not
* Browser controls loads JS, then on DOMContentLoaded leverages winset to hide the output control and show the browser control. This allows to use the Output as fallback while Browser has additional functionality.

Code Snippet (if applicable) to Reproduce Problem:
N/A

Expected Results:
Setting is-visible=0 on the Output control hides it, showing the underlaid Browser control instead.

Actual Results:
BYOND correctly sets is-visible=0 on the Output control, but doesn't actually hide it. The Browser control remains obstructed. It has to be set back to 1 then 0 again to actually hide it.

Does the problem occur:
Every time? Or how often?
About 5 to 50% of the time, depending on user and hosting location, hinting at a potential race condition.
In other games?
Presumably No. As far as I can see /tg/ uses the exact same code both in skin, DM-callbacks and JS, and i do not believe them to have this issue. I am still writing this as a BYOND bug due to winget reporting is-visible=0 while the control is visible.
In other user accounts?
Yes.
On other computers?
Yes both server and client

When does the problem NOT occur?
Does not occur on other codebases despite no apparent difference.

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.)
Yes, tested with 514 and 515.1610 server side and a variety of 514/515 clientside. IE compatibility is also wide.

Workarounds:
Setting is-visible to 1 then back to 0 correctly hides it.
This sounds like a skin use issue rather than a bug. I really need a smaller test case if there is in fact a bug, because running the full CM codebase to test this just isn't tenable.