AUI 9 Checkboxes in Confluence 7 Break Functional Testing Frameworks

Something we’ve noticed while testing the upgrade to AUI 9 in Confluence 7.12 is that all of our automated browser tests that interact with check boxes on macro forms now fail.

This seems to be because of the changes made to the DOM.

In Confluence 7.11 and earlier, the HTML for a macro’s checkbox parameter looks like this:

<div class="checkbox macro-param-div boolean-param" id="macro-param-div-somecheckbox">
    <input class="checkbox macro-param-input" type="checkbox" value="true"
           id="macro-param-somecheckbox">
    <label for="macro-param-somecheckbox">Checkbox</label>
    <div class="macro-param-desc">Check this box FOR GLORY</div>
</div>

In Confluence 7.12 (which uses AUI 9), it looks like this:

<div class="checkbox macro-param-div boolean-param" id="macro-param-div-somecheckbox" resolved="">
    <input class="checkbox macro-param-input" type="checkbox" value="true"
           id="macro-param-somecheckbox" resolved="">
    <span class="aui-form-glyph"></span>
    <label for="macro-param-somecheckbox">Checkbox</label>
    <div class="macro-param-desc">Touch the magic glyph for checkbox to happen</div>
</div>

That’s the markup from my browser’s inspect tool, by the way. It doesn’t seem consistent with the markup listed for Checkboxes in the AUI 9 Documentation at Forms - AUI Documentation, though I believe that may be because there’s some JS/CSS magic happening.

While we can work around the automated test problems (directing the tests to click the label or the glyph), this seems to be at least a bit anti-standard and raises concerns about accessibility. This could affect any browser-testing framework based on Selenium.

To our fellow partners, has anyone else run into this?

To Atlassian, what’s the driving reason to make the actual input element for the checbox non-focusible? What end does that serve? Also, can Atlassian change this aspect of AUI 9 without issue?

2 Likes

We noticed that AUI 9.x checkboxes broke in one of our p2 plugins when we tested it on Confluence 7.12beta1.

We haven’t had time yet to study root cause but it feels like a problem with focus management. Maybe a problem of the containing div taking focus now while it used to be that the checkbox took focus.

I am keeping a note about this thread, will post if I discover more.

I’d also like to see if this could be changed/fixed in AUI 9 without developers having to do anything.
In addition to that, if there is anything Atlassian can add to the story it should probably be added to the migration docs and other places that people are using during this time of upgrade to AUI 9:
https://aui.atlassian.com/aui/9.0/docs/upgrades/aui-9.html

Thanks.

1 Like

@jhronik You were helpful in another thread about details of the recent AUI 9 upgrade so I thought I’d bring this one to your attention in case it is familiar to you.

It seems that something related to focus of checkbox elements has changed in AUI 9 and might be the cause of some breakages for users of the older AUI versions.

Thanks.

Hi @jcarter @TureHoefner,

To Atlassian, what’s the driving reason to make the actual input element for the checbox non-focusible? What end does that serve? Also, can Atlassian change this aspect of AUI 9 without issue?

This change in AUI’s form styles occurred in AUI 8.5. The issue key was AUI-5053, and here’s the PR.

The reason this was done was to support the widest range of HTML patterns being used for form fields, while still achieving the ADG style. When using a pure-CSS solution, some markup patterns would end up with invisible glyphs for the checkbox or radio, which was a blocker.

The compromise was to add an additional explicit element via JavaScript and style that. The cost was the need to visually hide the <input> element.

As pointed out in this thread, Selenium doesn’t interact with hidden elements. It’s a reasonable default behaviour - try to emulate what a real user would be able to do. In this case, though, users are able to interact with these faux form field glyphs. Mouse and screen-reader users can click the <label> element, and keyboard users can still focus the <input> element.

You can adapt to the change in one of three ways:

  • Update your selenium tests to interact with the field’s <label> rather than the <input> element directly. Interacting with the label has the added benefit of testing that your forms are accessible to screen reader users, since it demonstrates the DOM has a link between the two.

  • Use one of Selenium’s lower-level programmatic APIs to find the <input> element and click it.

    WebElement el = driver.findElement(By.id("visually-hidden-input"));
    
    // this doesn't work out...
    el.click();
    // throws in webdriver 2 with something like "cannot click because another element is in the way"
    // throws in webdriver 3 with "cannot scroll element in to view"
    
    // this sometimes works out...
    (new Actions(driver)).moveToElement(el).click().perform();
    // works in webdriver 3 on zero-opacity, negative z-index, and clip-hacked elements ... 
    // fails in webdriver 3 if the element was clipped outside an overflow boundary.
    // fails in webdriver 2
    
    // this seemingly always works out...
    ((JavaScriptExecutor)driver).executeScript("arguments[0].click();", el);
    // works in webdriver 3
    // works in webdriver 2
    
  • Override AUI’s CSS rule for hiding <input> fields during tests, so Selenium’s default behaviours will continue to work.

    	form.aui:not(.aui-legacy-forms) .checkbox input[type=checkbox],
    	form.aui:not(.aui-legacy-forms) .radio input[type=radio] {
    		position: static;
    		width: auto;
    		height: auto;
    		clip: unset;
    	}
    

    (Note that changing styles may invalidate any visual regression screenshots you are taking!)

Whichever of these routes you take, I’d suggest you wrap them in an abstraction like a “page object”, so that tests can describe what they’re testing, and the abstraction can handle the how.

It’s an oversight that this technical change did not end up documented in the upgrade guide for AUI 8.5. I’ve raised [AUI-5341] Document radio and checkbox changes in AUI 8.5 upgrade guide - Ecosystem Jira to track an update to the guide. My apologies for this. I hope the details above will help unblock you!

Cheers,
Daz

5 Likes