This.render is not a function?

[benhtmn]

Occasionally woofjs freezes, requiring a reload, and the error message reads "this.render is not a function", while the little emoji thing glitches out, showing tons of different emojis. I don't have any specific case in which this error occurs (I'll make sure to keep an eye out in the future), but I've seen it multiple times so I figured I would make it known.

[stevekrouse]

Yeah, I've seen this too. It's not Woof's best moment. If anyone can create a reproducible example of this bug and paste it below, that'd be a great start towards debugging it

[stevekrouse]

+1 Another person chatted us to complain about this

UPDATE - turns out "The problem occured only under Safari but not with Chrome". Yet another reason to #531 check if chrome and warn if not.

[truthgoddess]

Actually, this happens to me on Chrome continually. I don't have to refresh the page. Very often I just increase or decrease the number of lines of codes by 1 or 2 and it fixes it. It seems to not be happening on my student's surface running chrome but it does on my surface running chrome.

[truthgoddess]

setBackdropURL("./docs/images/tomato-attack-backdrop.jpg")
setBackdropStyle("cover")

var unicorn = new Image({
url: "./docs/images/unicorn.png",
width: 120,
height: 80,

})
var bb8 = new Image({
url: "./docs/images/BB8.png",
width: 150,
height: 220,
})

That code with line 15 blank has " There's a problem.
this.render is not a function" the warning smileys cycle through them really fast, as if that error is happening repeatedly.

[handatoe]

i have mostly gotten this.render is not a function when my code is really long. mostly i just delete a character and it will go. but as soon as i do something else it comes right back.

[madduccino]

This is happening a lot now. Like in this project: https://woofjs.com/team.html#black-dragonfly

Not sure what's going on?

[stevekrouse]

I never looked into this issue. Every time it seemed worth looking into (it was happening a lot), it would then seem to stop happening as much. It may be time to (finally) actually look into it...

As you know, the first essential step to solving any bug is to first come up with a reliable way to reproduce it. That is the problem with this issue. For example, the above link does not trigger the bug for me. I messed around with that code a bit: no issue.

My best guess at this moment is that is somehow triggered by the quality of the wifi connection. Another guess is that it may happen when someone has a lot other tabs open.

In summary, I agree this is worth solving, so keep your eyes peeled for what potentially may be causing it so we can generate the reproducible bug.

[madduccino]

I see. I thought that I had finally replicated it in a way others would see! Usually we're able to fix it by changing a few lines and having it reload, but this time I couldn't get the error to go away. WiFi connection sounds interesting. I'll experiment with that.

[madduccino]

Other things to note that might be helpful:

1. The line error says "Uncaught RangeError: maximum call stack size exceeded"
2. It's only an error when in the Woof window. Not in the browser window.

[truthgoddess]

In the link that Maddy posted above (https://woofjs.com/team.html#black-dragonfly) I can reproduce the issue by bringing the cursor down to a blank line below all the code, and pressing enter. This will create another blank line of code, and often, cause the this.render issue. The issue can be resolved by adding one more blank line of code. It seems that if there is more going on (more browser windows open, more bandwidth being used) then the this.render error is easier to reproduce. If I introduce more loops and calculations into the project above, the this.render error is easier to reproduce. I'm not finding that there is consistency. It is not always that one more line fixes it or causes it. Sometimes it is two or three or more.

I wish I knew more to be able to help more. Had two kids get frustrated yesterday with the this.render errors (working on advanced projects) and move on to web development. Not a terrible end result, but I think the kids get emotional about woof when it throws errors at them that they can't understand.

I hope that helps! ~Kate

[stevekrouse]

(Nice to meet you Kate! I don't think we've met before, yes?)

Very well written comment! You analysis would lead me to believe we're dealing with a very persnicity race condition bug here. In other words, there's probably a bug in Woof that only occurs when the CPU is running slowly (because there's a lot of other things its trying to do at the same time).

For what it's worth, on a macbook I was not able to reproduce the issue via the methods you suggested above. However this would fit our theory: macbooks have much more CPU power than chromebooks so it's not surprising that an issue on a chromebook would not happen on my macbook.

So what I see now are two paths forward, a short path and a long path:

1. The short path - Your last comment about how "the kids get emotional about woof when it throws errors at them that they can't understand" was very insightful. I think we could attack this problem directly by simply "catching" these sorts of incomprehensible error messages and replacing them with something much friendlier. In particular it would be neat if we could communicate that the issue is likely not even their fault but a bug on Woof's part. Something like: "Something went wrong, but we're not sure what. If you keep seeing this error message, try refreshing the page. If that doesn't work, maybe try closing other tabs you have open. If the issue still persists, email us at ..."

2. The long path - Eventually someone will have to investigate what I likely consider to be a race condition. Basically my hypothesis is that the error "woof.render is not a function" is happening because parts of the WoofJS library are being loaded before other parts (but only when the CPU is freaking out). If I were debugging this, I'd start my analysis by searching the codebase for "woof.render" or "this.render" to see all the places that could possibly be triggering the issue. You could even add console.log statements above each of those lines and then try to reproduce the issue to see which log statement occurs right before the error is thrown. Just some suggestions off the top of my head - let me know if you'd like more help or advice :)

(To be clear, I don't have the time or inclination to work on such an involved WoofJS bug myself at the moment. If you feel like you really need my involvement on it, though, we can talk...)

[truthgoddess]

Hi Steve,

Nice to meet you too! I'm hypothetically and experimentally working on working on some WoofJS, so hopefully we will be able to build upon WoofJS. I love it.

Thank you for bringing some thoughts and technical expertise to the issue here. My thoughts are similar to your thoughts and I will troubleshoot this issue one more time on my gaming pc at home the next time I turn it on. That shouldn't have any problem at all, and if I can't reproduce it, then our thoughts are probably right!

Maddy suggested I look into your first idea and then second. Love both of them. Thanks for suggesting them!

[aas2306]

Had two kids get frustrated yesterday with the this.render errors (working on advanced projects) and move on to web development. Not a terrible end result, but I think the kids get emotional about woof when it throws errors at them that they can't understand.

Same happened to me yesterday! I had three students start on web development because this error has been making WoofJS pretty much unusable for us in the past few weeks.

[truthgoddess]

A few things for us (just food for thought):

1. Was able to recreate the error on my home PC by making a bunch of images. After it gets long enough, it shows up. That might be why this error shows up on students working on complex projects.

2. PC is currently using 3% of the cpu to view this page. It uses ~33% with woof open with the crashing code. With no code in the right window, WoofJS is using ~84% of my CPU. My CPU is a I7 8700K 6 core processor. My processor temperature at rest is ~34C. Within 2 seconds of opening Woof, my CPU shoots up to 55 - 65C. For comparison, when I open up Pillars of Eternity 2 on max graphics, my CPU is only at 55C. If I do the Intel burn test, the hottest my CPU gets is ~ 70C. So technically, Woof is raising the temperature of my processor to temperatures similar to those caused by a major game or stress tests, even without code in the window. After trying this a few times, I can see that the exact percentage used or the max of the temperature varies a bit, but it is always using a lot more CPU and raising the temperatures by a significant amount more than it should.

3. We could think about how we might make the code more efficient rather than try to fix this error. My theory is that with less processor utilization, the problem might disappear. Seems possible given the fact that the error is not constant and is connected to not finding the render function of some (yet) unknown object because of too many stacks it is processing.

[madduccino]

Another one of our awesome teachers, @bbah93, mentioned the idea that it could have something to do with a library or other dependency needing an update. This would make sense when trying to answer the question of why is it suddenly happening all of the time when nothing has changed on our end.

I’m wondering about CodeMirror. It seems significant that changing the number of lines on the editor creates or gets rid of the bug. Also when the error appears on the code editor, the project will not render on the Woof viewer, but it will render in full screen mode when the code editor is no longer in the window.

I took a Woof game that reproduces the bug easily (most things do for me on my super rad chromebook) and put it on jsbin bringing in the Woof library. I haven’t been able to reproduce the bug there. Can anyone else?

https://jsbin.com/nugika/6/edit?html,js,output