How can we restrict other plugins batch js files from getting triggered with our custom plugin?

Question

We have created a custom plugin in Jira, there recently we are facing click handler violation in console log. Upon checking we found that a batch js file is triggered which has the module of all other plugins which are been installed in Jira and one of the plugins is causing the timeout issue when our plugin is been used. So, how can we restrict access of other plugin batch js from getting triggered with our plugin.

We are open for any suggestions or any points you may have for the issue.

Radek Dostál · Answer

It's javascript, you can change and remove things. Just like you're interacting with your stuff, you can interact with somebody else's if it's getting in your way, e.g. removing listeners, removing or replacing functions, anything really.

There's no clear cut way of doing that since you need to know what impact it will cause and if it can affect anything else, or break something somewhere unintentionally. It certainly should affect that other plugin, then again the changes should probably be done in that other plugin if it's affecting your stuff - it needs to be scoped better so it doesn't interfere. Whatever you would do to workaround it is always at risk if the other plugin implements something differently.

Also I'm in no way saying it would be easy, because working with batched and minimized .js is.. surgery.

Novita Chelluri · Answer

Hi Radek,

We already have a separate context for the js of our custom plugin but still while loading our custom plugin the general batch.js is also getting triggered. Also, can you please tell what you mean by 'in your own js to actively check if their js is loaded, and if so, sweep it up to trash'?

Thanks for your response.

Radek Dostál · Answer

I believe it all depends on the web-resource's context. So if both plugins share the same context, they're going to be included in the js batch. So one way would be to not use a generic atl context (suc has atl.general in web resource, then atl.general as decorator on the page template). The other might be in your own js to actively check if their js is loaded, and if so, sweep it up to trash so your js can do it's thing unhindered.

Either way, no option is great, but unless I'm wildly misunderstanding how the contexts work then that is the cause.

Sounds like a funky .js if it's causing timeouts for another plugin, the heck it's doing? Preferable would be getting the vendor to fix their stuff, because who knows what else they are affecting.