What is changing?
The context.contentId property of AP.navigator.getLocation (see Navigator.getLocation) is changing from a number to a string . This is because Confluence contentIds can be up to 64 bits (a long ), which is larger than what can be represented in a JavaScript number (which maxes out at 53 bits of integer precision, see Number - JavaScript | MDN.
Old value - number
AP.navigator.getLocation(function (location) {
// location will be:
{
"target": "contentview",
"context": {
"contentId": 1234, // <- old value is number
"contentType": "page",
"spaceKey": "DS"
}
}
});
New value - string
AP.navigator.getLocation(function (location) {
// location will be:
{
"target": "contentview",
"context": {
"contentId": "1234", // <- new value is string
"contentType": "page",
"spaceKey": "DS"
}
}
});
Why is it changing?
We recently started seeing very large contentIds for certain customers, above normal limits that we’ve seen in the past. Our frontend not supporting large contentIds is a pre-existing bug, however it was rarely encountered in the past, until we started seeing more frequent usage of very large IDs. Any apps using contentId that cannot handle a 64 bit integer will not work correctly on pages with these very large IDs.
In practice, how this manifests is contentIds that are larger than Number.MAX_SAFE_INTEGER (eg 269528037047075906 ) will lose precision and cause the value to become incorrect, which can lead to either 404 errors, or referring to another existing but incorrect page, in any API calls using that contentId . To see this in action, enter this number in a JavaScript console:
> 269528037047075906
2269528037047075900
What do I need to do?
If you simply concatenate the provided contentId into a string for API calls in JavaScript, then you won’t need to do anything. Since JavaScript is relaxed about types, using a number or string is interchangeable in most scenarios where this contentId would be used.
However, if your app handles these contentIds in any other way, such as explicitly checking if they are numeric (eg contentId === 0 ), storing them in a database, or sending them to a backend running a strongly typed language, it could cause issues.
By when do I need to do it?
We have already started rolling out the change to a select few customers who are experiencing major issues as a result of not being able to use apps correctly with large Confluence IDs.
We will also begin rolling out this change to the developer first beta group starting today, so you can start testing this change works for your apps.
For general rollout, as we don’t anticipate widespread breakage for this change, and we want to expedite the fix for our customers facing issues, we are targeting a gradual production rollout starting 10 Jan 2022.