setTimeout workaround


I know the dev team is hard at work on implementing setTimeout but in the meantime, I needed some mechanism to get regular callbacks to my application for the purposes of debugging. In case someone needs a workaround, I’ll just leave this here. Warning that I wouldn’t ship with this code.

The trick requires a url that you know will not return a response and will eventually timeout. Then, all you have to do is make a request to that url and set the network timeout to whatever value you would put in your setTimeout.

There are of course caveats to this like it probably won’t work if you’re offline and if your timeout is greater than the standard HTTP default timeout. Still, it’s pretty handy until there’s a better solution.

Last note: this hack relies on recursion (which may be bad for the stack depending on how things are handled under the hood) but more importantly, documentRoot seems to be a reference to memory so even though we are technically passing the same documentRoot to each subsequent call, as you update your document, you will see documentRoot change.

function layoutCommand(selection, documentRoot) {
    // do something interesting here

    // our timer starts here
    const req = new XMLHttpRequest();
    req.timeout = 5000;    // here's our timeout
    req.ontimeout = function() {
        layoutCommand(selection, documentRoot)
    };'GET', '', true);


Thank you. We have the same issue with our cloud services :confused: with services than run in the background we need to setimeouts but for now you solution may be the best one.


Since we always want the request to timeout, do you know of a dedicated URL or IP that we can count on to always fail?

As an example, 127.0.01 is a reserved IP that’s used to refer to localhost,


I think a real problem is that this requires a request that actually times out and doesn’t just fail (“server-side”). Therefore, we’ll need to have a (real) website that achieves this (which – technically – wouldn’t be difficult, of course). Unfortunately, this gets us into trouble with the GDPR unless we sufficiently ask users to accept privacy policies (which cost a ton of money since – different to websites – there are no generators for privacy policies for plugins). Believe me: I wanted to implement simple analytics (which function of my plugin gets used), but failed due to privacy policy stuff :wink: – any http requests are pretty difficult :slightly_frowning_face:.

While I find the solution great (congratulations to @staufman for coming up with this), I don’t think it’s as simple as that from the non-technical aspects…


Agreed. As I mentioned, this is only useful for debugging (and at that, in the short term) and is not meant for production code. I’m sure the fine folks at Adobe will give us a better solution anyway.