With instructions from tsmith, I found this using grizzly [1] to fuzz the Canvas 2D API.

The attached test case causes a 30+ second Flush [2] on my machine during a Snapshot for line:
try{imd9=ctx3.getImageData(161,82,-40,268);}catch(e){}

Currently with remote canvas it will timeout after a number of waits and this can then cause the Translation to crash.
In a previous change I added a check to make sure the other side is still alive by checking the IPDL channel, so I'm just going to remove the limit on the number of waits.
This gives a similar behaviour to when this is just running in the content process, because that just has to wait on any long running Direct2D calls.

I'm setting this to block Release not Nightly, because I think these sorts of waits are probably fairly extreme examples.

[1] https://github.com/MozillaSecurity/grizzly
[2] https://docs.microsoft.com/en-us/windows/win32/api/d2d1/nf-d2d1-id2d1rendertarget-flush

It seems clear that we can get long delays waiting for Direct2D to process
things on occasion. So given that we now detect when the reader has closed,
instead of guessing at a suitably long timeout, waiting indefintely while it
hasn't closed seems like a better option.
This gives a similar behaviour to when this is just running in the content
process, because that just has to wait on any long running Direct2D calls.

https://treeherder.mozilla.org/#/jobs?repo=try&duplicate_jobs=visible&revision=9e1819bb3a036b5fe507ec7c6bdf0ec66b81d217

https://hg.mozilla.org/mozilla-central/rev/988672936c1b