Pixi.js: app.destroy() throws an error when accessibility is disabled

[drskullster]

If we don't want the extra div appearing for accessibilty, we have to use app.renderer.plugins.accessibility.destroy() (could not find another way in the doc or by checking the source code).

When we call app.destroy() we have an uncaught type error in console: "Cannot read property 'length' of null", which refers to app.renderer.plugins.accessibility.children.

Expected Behavior

No error should happen in console

Current Behavior

Error happens in console

Possible Solution

When using app.destroy(), Pixi calls core.utils.pluginTarget.destroyPlugins() which then calls destroy() method on all plugins. If we already destroyed a plugin, the method is thus called a second time.

There should be checks in AccessibilityManager.destroy() for when the method has already been called.

Steps to Reproduce

See jsfiddle: https://jsfiddle.net/drskullster/pyemkz4c/ (open console)

Environment

• pixi.js version: 4.8.2
• Browser: Chrome 68
• Device: Desktop

[themoonrat]

Your best bet is to perform a custom build without the accessibility plugin even bundled in
npm run dist -- -e interaction

(ps, some documentation on building versions is within the main page readme - https://github.com/pixijs/pixi.js#how-to-build)

[drskullster]

Thanks for your answer, but I'm not sure I (and my contractor) would want the overhead of doing a custom build.

I already worked around it (it's not pretty though) :

app.renderer.plugins.accessibility.destroy();
app.renderer.plugins.accessibility.children = [];

I've updated the fiddle with the workaround commented : https://jsfiddle.net/pyemkz4c/1/

I think this should be tagged as a bug, since the two destroy() methods are public and documented, and the pattern seems legit : deactivate accessibility plugin and destroy app at some point.

[englercj]

I think the problem is that you destroy the plugin, but don't remove it from the list of plugins on the renderer. So later when the renderer is destroyed it thinks the accessibility plugin is still active (since it is still in the list) and tries to destroy it again. Double destroy is almost always an error.

There is currently no API to remove a plugin, because the philosophy was to exclude the plugin from build if you didn't want it.

[drskullster]

Thanks for your answer @englercj.

I think the API to remove plugins would be a good idea. Making a custom build would require me to either fork this repo (but I don't want to maintain a fork) or force my team (and the CI/CD environments...) to clone as a submodule, install dependencies and run the build step. Or am I missing something ?

Another idea would be to distribute a "bare" Pixi.js, without plugins, in your npm builds.

[bigtimebuddy]

If you do not want to create a custom build, delete the accessibility from the list of plugins. This fixes the crash.

app.renderer.plugins.accessibility.destroy();
delete app.renderer.plugins.accessibility;

Unfortunately, we will not be adding new APIs to v4. Good news is that these problems will become _much easier_ in v5 because you'll be able to compose your own version of PixiJS without creating a "custom" build. Instead you'll be able to import modules for only the pieces you need and add only the plugins that are relevant.

[englercj]

Making a custom build would require me to either fork this repo (but I don't want to maintain a fork) or force my team (and the CI/CD environments...) to clone as a submodule, install dependencies and run the build step. Or am I missing something ?

You don't need to do either of those. You can just make a custom build of pixi and commit the output to a 3rdparty folder. Then on the rare occasion that you need to upgrade, simply do it again. It is a small, single file that changes rarely so it isn't a big deal to stick it in the repo.

[drskullster]

@englercj I'd like to avoid versioning dist files if possible. I could also create another repo, but I'd still have to manually run the build at every release, however rare. Or create an environment especially for this, which seems overkill.

@bigtimebuddy that's definitly prettier than what I had, I'll go with this.

Thanks everyone for taking the time !

I'll try v5 when I have time, looks cool :)

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.