Tablet HTML loses webEventReceived connection if script(s) reloaded


I have my first tablet app (based on the Create an Avatar Switching app) here:

It seems to work fine if the script loads when I first run Interface, but if I reload the script (or reload all scripts) the HTML page onready and buttons no longer fire the webEventReceived callback in the main script. I just wanted to check if I was misunderstanding or doing something wrong. It’s hard to code/debug if I have to restart Interface each time.

I also seem to always be fighting against caching, but that’s another topic (I assume).



Does the thing where u put a ?123 after the URL work on scripts as it does with models. So www.script?12


I’m seeing a similar issue, the script tends to block the tablet and you get this phantom tablet image that doesn’t work when clicked. Its like the script does not unload the tablet on reload…


Ok. What I’m seeing as caching may be what @whyroc described. Oddly, when I see it “cached” it’s sometimes from several version before. And it doesn’t seem restarting Interface always resolves it.

The issues with refreshing seem more pronounced when using the desktop menu vs the tablet. I imagine it’s because the tablet UI does some additional execution/reloading.

I’m using query strings to cache-bust, both on the loaded JS and the gotoWebScreen HTML, but it’s not clear whether it has any affect.


… a few more details to add to the mix. Right now it seems all Tablet applications overlap with each other and will often receive all other app’s messages (ie: over their “own” event bridge connection…).

And then of course reloading-all tends to break everything outright.

But anyway, at least this explains why error messages like this keep showing up in the logs:

[2/28 19:9:23] [defaultScripts.js] Script received a web event, its type is string
[2/28 19:9:23] [defaultScripts.js] ERROR - [UncaughtException signalHandlerException] Error: Unable to parse JSON string in /~/scripts/system/tablet-users.js:72
    onWebEventReceived(event = 'foobar') at /~/scripts/system/tablet-users.js:72
    <global>() at -1

(… because when any other app’s content emits a message – if there are other apps listening at all then it triggers their onWebEventReceived handlers too…)

Can be confirmed using the Console… with:


Has anyone filed bug reports for any of these issues yet? (If so please add links to them here)


I hadn’t filed one for the reloading-breakage problem yet, but planned to do so. I’ll try to get that done by tomorrow.


In the processes of reproducing the issue on the latest dev build (as instructed by the repo) I got myself into a state where no scripts load, not even the default (so the menus are dead). Is there a way to restart Interface in its default state (vs re-installing it)?


Did you try to remove the defaultscript.js from running scripts and then reload it ?
Otherwise you could remove the interface.ini from the high fidelity user directory and try it again.

A bit more info in this topic.


Thanks, @Richardus.Raymaker. I found that Running Scripts… worked and found the defaultScript.js to reload, so got things working again. (I really hope I had tried that previously and didn’t work. Otherwise, shame on me)