AUI is being upgraded to v8.8.4

[JohannaNelson]

Note: AUI 7.6.2 was originally released on June 12, and due to various customer issues, we have decided to rollback the AUI 7 upgrade to reduce further customer impact. We will re-release AUI 7.6.2 on a later date once we improve upon our internal testing process for marketplace apps. Thank you for your patience.

Hi developer community,

We’re in the process of upgrading the AUI version used by Confluence Cloud from v6.3.2 to v8.8.4.

The upgrade will be released in the following four phases, at later dates to be determined:

1. v7.6.2
2. v7.10.3
3. v8.3.12
4. v8.8.4

NOTE: For future AUI upgrade release announcements, we’ll be posting new notes for each upgrade as DAC changelog entries, due to Confluence Cloud announcements becoming read-only.

Link to changelog entry for AUI 7.6.2: https://developer.atlassian.com/cloud/confluence/changelog/#CHANGE-983

The changes between versions will all be visual, with updates such as minor CSS revisions and replacing outdated iconography. Furthermore, they will only affect surfaces throughout Confluence that plugins might extend; these changes will not affect the plugins themselves.

What does this mean for me, the developer?

If your Confluence Cloud plugin is using an older AUI version, you will need to evaluate any visual differences in styling or branding as a result of using AUI class names - we are not changing plugin styling, but your plugin’s style might clash with the updated host page style.”

AUI provides detailed upgrade guides for each 7.x and 8.x version:

• v7.x Upgrade guide
• v8.x Upgrade guide

Notes for Upgrade #1 (Upgrade from v6 to v7.6.2):

• If your plugin is using AUI iconography, it’s possible that your icons are deprecated. This section of the upgrade guide provides a chart with old and new icon names.
• If your plugin is using hardcoded color values, they may be inconsistent with the new color scheme. This section of the upgrade guide provides an overview of the color updates, and the AUI 7.6 documentation provides more details.

Visual Differences between AUI Components v6.1 & v7.6:

Component Name	6.1 (documentation)	7.6 (documentation)
Toggle Button
Avatars
Badges
Buttons
Modal dialog
Dropdown2
Flag / Messages
Icons	See Icons - AUI Documentation	See Icons - AUI Documentation
Lozenges
System notifications
Tabs
Toolbar 2
Typography	See Typography - AUI Documentation	See Typography - AUI Documentation
Navigation	See Navigation - AUI Documentation	See Navigation - AUI Documentation
Page header

[thomas2]

these changes will not affect the plugins themselves.

Well, the first phase roll out already did affect a bunch of plugins, so we would appreciate if the process for ensuring this would be improved for future phases.

A simple suggestion I want to put out there is to roll out updates like on instances in the Developer Canary Program first and after a fixed time later roll it out to the general public if no breaking changes have been reported.

[tonyanziano]

@thomas2 Thank you for the input, and we will definitely take this into consideration. It might make sense to test the future AUI changes in Canary going forward. We are also internally investigating ways we can improve our automated testing process to cover such a scenario.

[SteffenMueller]

Dear @JohannaNelson, Dear @tonyanziano,

the upgrade seems to have an undesired impact on our app.

The context: We use a webItem with target type “dialog” without chrome in our atlassian-connect.json to offer a configuration dialog in the overflow menu of pages. Inside of the iFrame, we render an atlaskit dialog.

Behavior until now: the AUI dialog2 body that contains the iframe had a transparent background, letting our atlaskit dialog inside the iframe look “like a real dialog”.

Problem first seen today: the AUI dialog2 body now has a #FFF background, creating a white box around our atlaskit dialog. There’s no documented option to switch this and it’s outside of our control as the AUI dialog2 body is rendered in the host application.

Desired solution: Return to the old behavior and let the dialog2 body have a transparent background. If this is not feasible because there’s a bigger plan behind this, at least offer an option for the target type dialog to switch the background to transparent.

Steps to reproduce: Just have a look at our public cloud demo here. Open the overflow menu at the top right, choose “Slide Presenter” and marvel at the white box.

I’d really appreciate a quick solution to this as it looks like we don’t know what we’re doing to our customers. Also, I think this is a good argument for the canary process @thomas2 proposed

[daviddrawio]

Just to add to the need for testing on canary first, we had pretty significant feedback from customers that were pretty astonished that such as https://jira.atlassian.com/browse/CONFCLOUD-75996 could happen.

This includes some of Atlassian’s largest customers on cloud. They absolutely expect that the changes be made visible to us prior to going live and that we test that prior to that date. And, clearly, they are correct.

If something like 75996 were to happen again due to lack of such a process, paying users would be entirely justified in a strongly worded message about the lack of our joint testing.

[tonyanziano]

@SteffenMueller thank you for the detailed report! We are aware of some remaining issues, including the white background, and are looking into them.

We will be soaking future major AUI changes in Canary.

[remie]

@tonyanziano is this also related? The post install dialog is pretty… euhm… big on a large screen.

[JohannaNelson]

After several attempts to resolve various customer issues, we have decided to rollback the AUI 7 upgrade to reduce further customer impact.

We will re-release the AUI 7 on a later date once we improve upon our internal testing process for marketplace apps.

Thank you for your patience.

[remie]

I’m sorry, but I feel like we need to address the elephant in the room here

We’re talking about a double major version update (6 to 7 to 8) of a UI library on a flagship product of a publicly traded company with a market cap of 45B, who regularly boasts about being a visionary leader on team collaboration and stakeholder management, of which at least 70k+ instances affecting 17.558.008 users have an app installed*, where the product teams have completely failed to do basic QA with their partners even though the process to do this is already in place (Developer Canary program), who decided to deploy without prior announcement and only found out after a complaint from the community and rolled back 4 days after the first notification.

Can I expect that a detailed PIR will be published on the Atlassian developer blog (maybe even by Atlassian CTO), including an apology to all customers and Marketplace Partners?

I mean, can we at least get any sign that Atlassian understands that she royally fucked up?

*) see builtwithconnect.com, filter on Confluence and order by number of users

[MattiaLomazzo]

Hello, after the announcement of the rollback yesterday, I checked the one dialog of our app and it was displayed correctly again.
But today this is no longer the case. Has there been another release since yesterday’s rollback?
Edit: This appears to be a problem on our end. Sorry for any confusion my question may have raised

[scott.dudley]

There are also now some random rendering updates happening after page load, with elements flipping between different AUI styles.

Certain CSS styles are currently being shipped in prod with a selector of body[data-aui-version] .whateverClass with a specific style, in addition to the original .whateverClass selector with different styling.

One problem is that the data-aui-version attribute in the main Confluence frame is not even added to the <body> tag until a long time after DOMContentLoaded, so the user first sees elements rendered with the old AUI style, and they later get re-rendered with the new AUI style when the attribute is added.

Can this data-aui-version attribute at least be added to the <body> tag when it is first delivered? Or at least before content is shown to users?

–

UPDATE: OK, so I was wrong and data-aui-version is actually published at page load. The real problem is that some overriding CSS is loaded much later.

For example, in https://confluence-v1-canary.prod.atl-paas.net/packages/confluence-editor/src/editor-plugins/status-macro/plugin.js, it invokes stylesEditor._insertCss() long after the page is loaded, and this generates new CSS containing body[data-aui-version] .whateverClass selectors that cause re-renders of existing content and a mismatch of AUI styles.

This is still a regression from a few weeks ago.

[scottohara]

This may be completely unrelated, but is it possible that this attempted AUI upgrade caused any behaviour changes to the AP.confluence.getMacroBody() JS API?

We have a long-term customer (who has been using our app successfully for a number of years) who reported that around the same timeframe of the ill-fated AUI upgrade, our plain-text body macro would render correctly in edit/preview mode, and correctly on first render when publishing the page; but after refreshing the page or navigating away and returning, it would render an error. Editing and republishing would temporarily fix the issue, but the cycle would repeat.

The customer can repeatedly reproduce the issue on an otherwise empty page with just this macro on it.

We have been unable to replicate the issue in any of our environments; but we have seen an elevated rate of corresponding errors in our Rollbar.js error tracking, that suggests the same issue is impacting other customers as well. The rate of errors increased around mid-June.

The customer kindly assisted us in troubleshooting, by following our instructions to set some tactical breakpoints/logpoints in our client-side JS code; to inspect the value of the body returned.

For this particular macro, the plain-text body is expected to be valid JSON or YAML.
On edit/preview/first render after publish, the callback for AP.confluence.getMacroBody() is called with the expected JSON/YAML.

However on subsequent page renders, the callback is called with what appears to be HTML for the macro block itself, e.g.

<div class="ap-container conf-macro output-block" data-hasbody="true" data-local-id="0cbc2751-b749-4e35-81eb-c1cefa884acd" data-macro-id="673b21b5-3d02-46e7-a128-31e71b14b963" ....>
  <div class="ap-content " ...></div>
  <script class="ap-iframe-body-script">//<![CDATA[
  (function(){
    var data = {
      "addon_key":"...",
      "uniqueKey":"...",
      "key":"...",
      "moduleType":"dynamicContentMacros",
      "moduleLocation":"content",
      "cp":"/wiki",
      "general":"",
      "w":"",
      "h":"",
      "url":"...",
      "contextJwt": "...",
      "structuredContext": "...",
      "contentClassifier":"content",
      "productCtx":"...",
      "timeZone":"America/Chicago",
      "origin":"...",
      "hostOrigin":"...",
      "sandbox":"allow-downloads allow-forms allow-modals allow-popups allow-scripts allow-same-origin allow-top-navigation-by-user-activation allow-storage-access-by-user-activation",            
      "apiMigrations": {
        "gdpr": true
      }
    };

    if(window.AP && window.AP.subCreate) {
      window._AP.appendConnectAddon(data);
    } else {
      require(['ac/create'], function(create){
        create.appendConnectAddon(data);
      });
    }

    // For Confluence App Analytics. This code works in conjunction with CFE's ConnectSupport.js.
    // Here, we add a listener to the initial HTML page that stores events if the ConnectSupport component
    // has not mounted yet. In CFE, we process the missed event data and disable this initial listener.
    const __MAX_EVENT_ARRAY_SIZE__ = 20;
    const connectAppAnalytics = "ecosystem.confluence.connect.analytics";
    window.connectHost && window.connectHost.onIframeEstablished((eventData) => {
      if (!window.__CONFLUENCE_CONNECT_SUPPORT_LOADED__) {
        let events = JSON.parse(window.localStorage.getItem(connectAppAnalytics)) || [];
        if (events.length >= __MAX_EVENT_ARRAY_SIZE__) {
          events.shift();
        }
        events.push(eventData);
        window.localStorage.setItem(connectAppAnalytics, JSON.stringify(events));
      }
    });
  }());//]]>
  </script>
</div>

We’ll raise an ECOHELP to formally request assistance from Atlassian, but given the coincidental timing it got us thinking whether it could be in some way related to the aborted AUI upgrade?

[scottohara]

Further to my comment above regarding the error we’re seeing with AP.confluence.getMacroBody(), our error monitoring confirms that we first saw this error occur on 9 June 2023 at 7:40am AEST (Australia, GMT+10).

This is the same date as the AUI upgrade entry in the Confluence Cloud changelog.

We continue to suspect that this is somehow related to that change.
We can reliably reproduce the problem in a number of our instances.