ID:2211145
 
BYOND Version:"511.1373"
Operating System:"windows 7"
Web Browser:
Applies to:Dream Seeker
Status: Open

Issue hasn't been assigned a status value.
Shadowlight213 wrote:
MrStonedOne, I'm getting an issue where the admin interfaces and stuff wont load, and will just be a white screen sometimes.
Retrying will usually fix it, but it's super annoying

Is one example, but i've gotten reports from users and other admins.
I'll need a lot more info on this: screenshots and the like.
Ok, further testing has shown that it only occurs the first time that it's opened, and the delay seems to occur for about 15 to 30 seconds. I'll try and get a screenshot of it.
It doesn't seem to occur every time either.
Ok it's gotten more common for me now.
Basically getting this every time I open an html window for the first time after the server boots. Sometimes it can even happen twice.
This doesn't seem to have anything to do with the time since world start either, as I've had it occur 30 minutes in.

Shadowlight, I suspect you may have antivirus and/or firewall software interfering here.
I tried modifying my av and firewall settings to exempt byond and dreamseeker. Not getting any change
Problem continues to intensify.
Sometimes it shows a little loading icon by my cursor, sometimes not.
Just earlier today, I had a window open fine, closed it and tried to reopen it and had the white screen appear.
Users on Goonstation have experienced this problem as well. However, in addition, it spawns lots of dreamseeker.exe processes forever that eat up memory on your computer and eventually crash unless you force-close the game dreamseeker process.
This keeps happening.

I finally got it to happen to me! Yay!

I can confirm that the file gets to the users cache but after being written no attempt to read it happens.

I can also confirm (via packet capture) that no attempts to actually request the page from ds occurs

Edit: ya, the window opens, but no navigation attempt happens. Moving your mouse around the window causes a loading icon to show and flicker, but it goes away the exact moment the mouse stops moving.
More data!


I used winspy++, started with the main browser window, and worked my way down the children. so window -> #somenumber -> shell embedding -> shell doc object

I did this on both.

The left window is a working one.

The right window is a non-working one.

As you can see, the inner IE webcontrol is never created in the right window.

That should hopefully narrow this down.

Edit: I just noticed, I'm still on 1383, I'll upgrade later, hopefully that doesn't matter. It doesn't look like anything related to this was changed.

edit2: after 5 to 10 minutes the browser control shows up with navigation cancelled
Bump.

The only problem is, I can't replicate this. I don't know why the required control isn't being created.
Ya, i feel it, I was hoping that hint might trigger some ah ha! moment.

We know it has to do with the control not loading immediately.

We know that no attempt to connect to the DS webserver happens

We know that the window is created.

We know it has to do with the 1373 (i think) change to how DS loads the html windows to a webserver framework.

That SHOULD narrow it down pretty far.

Maybe go over the diff for that version and look for obvious fuckups. The randomness of the bug suggests it would likely be a uninitialized read or maybe an overflow/underflow/out of bounds issue.

Because the underlying code for the browser control didn't change all that much, I don't think that's it. I suspect there's some sort of bizarre timing issue in play.
New data: So, not only does this not trigger on skin level browser controls, triggering a navigation on them actually fixes all other broken browser winodws.

This should give you a narrow bit of code to check in on.
Not sure if this is helpful, heck perhaps even related, but. I've got reports of players getting blank white from the following. It seems to work fine offline, though.

world.version_notes = file("updates/updates.txt")

usr<<browse(version_notes)

In response to MrStonedOne
MrStonedOne wrote:
New data: So, not only does this not trigger on skin level browser controls, triggering a navigation on them actually fixes all other broken browser winodws.

This should give you a narrow bit of code to check in on.

I'm not sure I follow. Do you mean that browse() sent to browser controls explicitly defined in the skin works, but popup browse() does not?

Technically both are skin-level controls of course, since the popups become temporary members of the skin.
I'm not sure I follow. Do you mean that browse() sent to browser controls explicitly defined in the skin works, but popup browse() does not?

yes. and new news! It only happens if it's the default browser control.

Doing a browse() to the default browser skin control will work, but a browse() that creates a new window will not work, the window will be blank white. On top of that, doing a browse() to the default browser skin control will fix all currently open temp browser windows that are just white.

In fact, I think it might be that all non-default browse()s don't work, since i saw issues with assets getting to clients, and our system uses browse()s to a hidden browser skin control as a signal to know when something has worked its way thru the browse() queue on a given client, so those not happening would explain a couple other symptoms.
bump.

I'm hoping that this is a significant hint as to the cause since it affects default and non-default browser controls differently, meaning any bugs have to arise out of some difference in code between the two, and there is very likely not much code that is different.

Also, i should point out, in all cases we specify the control, even when browse()ing to the default control.
Bump Episode 2: Attack of the Stoner

To recap, for users this triggers on browse() breaks to all non-default browse controls, browse()ing to a default control temporarily fixes the issue including all currently open but blank windows.

It could also be related to something ABOUT our default control. Our default browser control is goonchat (browser control based output control replacement), and browsing to it could be aborting some blocking function, but for these people, they report that goonchat loads and operates just fine, so I don't see how that could be the case.
Page: 1 2