Bug with drainQueue
See original GitHub issueIf a render function throws an exception when invoked via drainQueue
future async renders are never triggered again. This occurs because the rafId
is not reset until after all the render calls have been successfully run, and the exception aborts the entire function.
The most correct solution would seem to be to try/catch the render call:
try { vm.redraw(true); } catch(err) { console.log("[DOMVM] Redraw Error:",err); }
Although it would be possible to move the rafId = 0
to before the loop, that will then leave the redrawQueue
uncleared, which will accumulate redraw requests, continually fail at the same faulting component, and it would also fail to invoke the didRedraws
hooks.
Whether to silently fail or log is an orthogonal question. Given that this will always be a programming failure, it seems very incorrect to silently fail. One option is to log only for the developer package, but I personally would hate that as I almost never think to revert to that package until I’ve expended hours trying to find a bug.
Stack Trace (ironically the Firefox trace included async precursor traces and as a result the problem was actually much harder to understand):
(@leeoniya – explicitly tagging you, per request)
Issue Analytics
- State:
- Created 2 years ago
- Comments:12 (4 by maintainers)
Top GitHub Comments
merged my branch.
i’ve added you as a collaborator, feel free to make PR with proposed changes. a test for this scenario would also be helpful.