Deprecation messages in log (document.registerElement, etc)


#1

Hello, could anyone please explain why clean Jira Cloud has this warning messages and what’s the proper way to work with it?

[Deprecation] document.registerElement is deprecated and will be removed in M73, around March 2019. Please use window.customElements.define instead. See https://www.chromestatus.com/features/4642138092470272 for more details.

DEPRECATED JS - Cookie has been deprecated since 5.8.0 and will be removed in a future release. Use cookie instead.

DEPRECATED JS - Dropdown constructor has I saw answers like “ignore, everything is ok”. been deprecated and will be removed in a future release. Use Dropdown2 instead.

I saw answers like “ignore, everything is ok”. That’s okay, I believe in Atlassian and it’s easy to just ignore. But I want to understand the reason of this deprecation messages. Is batch.js comes from Jira core? Or…how it works? Where could I learn more about it?

I can ignore things, but also I want to get the proper way of thinking. Thanks you for coming in.


#2

I want to understand the reason of this deprecation messages. Is batch.js comes from Jira core? Or…how it works?

Hi @piskunovigorm, these are reasonable questions to ask :slight_smile:

The batch.js file is something that Jira itself constructs and serves. There can be several per page, and their contents can vary depending on what features are present on a given page.

The original mechanism for constructing these batch files in Atlassian products is the Web Resource Manager and Atlassian’s P2 plugin system. There are other mechanisms in Cloud products, but this is the most likely source of a batch.js file.

Since Cloud products use Atlassian Connect instead of P2 for enabling their plugins, there is a clear division between Atlassian’s code and plugin’s code – the batch.js files will only contain code that Atlassian developers have written.

That covers where the batch file comes from, but not where the deprecations come from.

Atlassian’s products are written by numerous teams and composed of a myriad of components. Each team has the ability to deprecate aspects of their components and log a message to indicate that a deprecated code path is being used. This deprecation mechanism is rather blunt: if the deprecated code path is used, a message is logged – it doesn’t matter whether it’s “your” code or someone else’s; it doesn’t matter if the application is in development or production mode.

With this context: the most likely reason for seeing these deprecation messages is that one team released a newer version of their component, the core product team updated to a dependency that ships this version + the old version, and there are still usages of the older version in the product’s UI code.

For the deprecation messages to disappear, the old component version usage would need to be refactored out by the product team.

The reason you need not worry about these messages in Cloud is because of that division I mentioned earlier: Atlassian Connect code is largely unaffected by the UI code the core product ships. The core product team is responsible for ensuring its UI continues to work after upgrading dependencies; the deprecation message is there to inform them of technical debt to be downpaid before they can upgrade that dependency again.

Hope that helps clarify further. If you’ve got follow-up questions, don’t hesitate to ask them :slight_smile:

Cheers,
Daz


#3

Awesome answer like a present under the Christmas tree. Thanks a lot!
Wish you all the best. :slight_smile:


#4

No worries!

I noticed I missed one specific deprecation warning that you mentioned about document.registerElement. That specific deprecation warning is output by the browser, in response to code in the AUI library. There’s an issue raised about it in AUI’s backlog: https://ecosystem.atlassian.net/browse/AUI-4959

The short story about this warning: there’s no need to worry, as the library already has a fallback behaviour with a negligible performance penalty.