Prevent infinite loops from crashing the site about dwitter HOT 11 CLOSED

When OfflineCanvas is done we can use that: https://developer.mozilla.org/en-US/docs/Web/API/OffscreenCanvas

from dwitter.

I looked in to this issue a little. It would be challenging to use web workers to detect infinite loops.

Dweets reference a DOM element (c) and a graphics context (x). Code running in a web worker can't create these types of objects. I also tested passing a DOM element in a message to a web worker: this doesn't seem to be possible either.

So, it seems that c and x can't be initialized inside a web worker. If c and x can't be initialized, then the web worker check will only catch infinite loops in code with no references to c or x.

One option would be to create mocks for the DOM element and graphics context classes, then use those mocks to initialize c and x.

from dwitter.

I had another idea: It might be possible to replace calls to functions on c or x before running the code. Maybe with something as simple as a regex, like x\.[a-zA-Z]+. And replace with (function() {}) or something similar.

I guess we'd have to worry about assignment too. Delete everything that matches x\.[a-zA-Z]\w*=[a-zA-Z0-9]+. And we'd have to worry about reads from properties.

It wouldn't catch all references to those objects, and it'd be easy to circumvent (e.g. c['width']). But I think it would make the editing experience more pleasant.

In this situation, it'd be really nice to have something like Ruby's method_missing. It would be easy to create mock objects that respond to any method call or assignment.

from dwitter.

CodePen detect and break out of infinite loops by instrumenting the code: https://codepen.io/quezo/post/stopping-infinite-loops (explanatory screenshots here)

This might have a small performance hit, noticeable on really long loops. That technique could be applied while developing dweet code, but not on published dweets.

They have made their code publicly available: https://blog.codepen.io/2017/03/23/infinite-loop-buster-round-three/

from dwitter.

Instrumenting the code is a pretty good idea! Would even give us finer control both in terms of timing or in loop iterations. I would be happy with such a solution.

from dwitter.

This might interest you: https://jsfiddle.net/mdnn5c6j/37/

Still needs some work, it handles the functions well, but doesn't keep track of properties (globalAlpha, fillStyle, etc.) and doesn't have the usual dwitter boilerplate (e.g. helper functions)

It basically sandboxes the code, does the time out and handles canvas drawcalls in a message queue

from dwitter.

Interesting! Can draw some simple stuff :) I worry about being able to get the full dwitter experience piped through the stack though, as this is essentially a white-listing technique. Then again, that might not be too bad. Also interested in seeing some performance numbers.

The more I think about it, I'm leaning towards the CodePen solution mentioned by @joeytwiddle. It leaves the code to run in the same way with a few additional conditional statements. Though I'm curious to see what the performance implications are here as well. Intuitively I would expect this to be faster than a message passing webworker.

So if someone has some spare time and want to play around with some performance measurement, let me know what you find out. For both suggestions.

from dwitter.

Interesting that we're exactly back to the same place mentioned by @iver56 on sigvef/arktis-tweet-demo#4 :P

from dwitter.

Mine technically doesn't need the canvas mirror, unless you want to sandbox it. You can just use it once, and if it isn't infinite, run it normally.

from dwitter.

@lionleaf I think this can be closed

from dwitter.

Same with #15

from dwitter.