From f2de58db8cac3c0f10aa4e8e001b0e310be4a73e Mon Sep 17 00:00:00 2001 From: Vincent Petry Date: Fri, 30 Oct 2020 00:03:24 +0100 Subject: Work around snap.js state mess Snap.js is not robust enough to prevent multiple calls to open() or close(), so we added more checks to prevent these happening even when an animation is in progress. Because if we let this through, snap.js will not notice that the animation is already done (or a duplicate animation was started), so the "transitionend" event will not fire a second time. During an animation, snap.js sets up a setInterval() that hogs the CPU during the animation. Since a transition doesn't always end due to the above conditions, that CPU hogging would stay forever. This is the best workaround so far, it seems it's not possible to cancel that interval from the outside nor to trigger events to make it do so. Signed-off-by: Vincent Petry --- core/js/tests/specs/coreSpec.js | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'core/js/tests/specs') diff --git a/core/js/tests/specs/coreSpec.js b/core/js/tests/specs/coreSpec.js index 13a8d4a0494..8adea2123e0 100644 --- a/core/js/tests/specs/coreSpec.js +++ b/core/js/tests/specs/coreSpec.js @@ -903,11 +903,15 @@ describe('Core base tests', function() { beforeEach(function() { snapConstructorStub = sinon.stub(window, 'Snap'); - snapperStub = {}; + snapperStub.enable = sinon.stub(); snapperStub.disable = sinon.stub(); snapperStub.close = sinon.stub(); + snapperStub.on = sinon.stub(); + snapperStub.state = sinon.stub().returns({ + state: sinon.stub() + }); snapConstructorStub.returns(snapperStub); -- cgit v1.2.3