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?

3 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

7 Likes

Thanks a lot @daz !

As a reference for which AUI version is with which server product: atlassian / platform-module-usage / wiki / aui — Bitbucket

So Confluence 7.11 is AUI 8.3.5.

I think I knew that but I’m putting it here so folks can see:
Confluence 7.11 → Confluence 7.12
is
AUI 7.3.5 → AUI 9.
This Confluence Server upgrade is jumping from AUI 8.3.5, past AUI 8.5, to AUI 9.

1 Like

Thanks, @daz . That’s a very clear, thorough answer. Respect. :slight_smile:

We use the page object pattern pretty heavily by way of Geb’s Modules and Page Objects, so no problems there.

The way we’ll deal will be to rely on label clicking, which will reliably work across all Confluence versions we support. While we have access to the Selenium APIs and could also override the AUI styling, I’d rather not. That sounds like a maintenance nightmare. :fearful:

1 Like

@daz my use case isn’t a UI test that can’t click on the checkbox anymore… my case involves the behavior of the user clicking on a checkbox vs clicking on the label.
When they click the label we open an editor for them to inline edit the label for the checkbox.

We use an AUI form for the checkboxes, per Forms - AUI Documentation

Now, with AUI9, a click on the checkbox is handled as a label click and the editor opens. There is no way for the user to click on the checkbox to change the value because we use the label click to open the editor.

I’ll probably end up handing this to one of our front end developers but I’m trying to get better at front end dev. If there are any tips you can give me I’d appreciate it. I’m going to need the solution to work in both AUI8x an AUI9x. I’ve used conditional logic based on the AUI version in our dialog2 “close” widgets to make them work a/ AUI9 (and the old versions) so I’m good there. However, I don’t really know where to start for either turning off this AUI9 behavior so I can make the checkbox clickable or do whatever other solution would work. I need to be able to handle the label click separately from the checkbox click.

looks like this when the editor for the label is opened

<input id="fb_checklist_item_checkbox_48" type="checkbox" class="fb_checklist_item_checkbox checkbox" resolved="">
<span class="aui-form-glyph"></span>
  ::before
</span>
<label for="fb_checklist_item_checkbox_310" class="edit js-edit-checklist-item-title">
  <form class="animated fadeIn aui">
    <input type="text" class="text focus-visible" autocomplete="off" name="value" data-focus-visible-added="">
    <button type="submit">Save</button>
  </form>
</label>

If it’s over my head, that is OK, you don’t need to try to explain it to a caveman :slight_smile: I can hand this off but I want to take a shot at it first.

Thanks.


UPDATE:
I did a quick test to inline the styles on the input to turn off the checkbox hiding (style=“position:static;width:auto;height:auto;clip:unset”) but I can see that isn’t going to get me what I need for our plugin. This would work for a Selenium test but it has to look good in our plugin:
override_hide_input

I think I’ll go ahead and get one of our front end experts on it… I can see this is going over my head.
Thanks!

1 Like

Hi @TureHoefner,

This does sound like something that needs a bit of design thinking put in to it. I’d need to better understand the intended behaviour and visual presentation of the UI to offer sound alternatives.

What I can say is that using a <label> as a trigger for javascript behaviour is going to cause problems for a decent chunk of users. The affordance of the <label> HTML element is to caption a form element and to provide programmatic access to the form element. For mouse users, this results in a larger hit area to make interaction easier. For screen reader users, this helps describe what the field’s intent is. By overriding the affordance, keyboard-only users and screen reader users will be locked out of the behaviour, and people with reduced motor ability will also have difficulties.

If you want to discuss the user-case further, feel free to reach out to me in a DM, I’d be happy to better understand the intent and help find a solution :slight_smile:

Cheers,
Daz

1 Like

Thanks @daz!

Our label is editable using jquery’s jeditable library (An “edit” CSS class identifies it). Imagine a checklist of tasks that can be toggled but also renamed after the task list is created.

Thanks for the offer of help, that is very brave because I’m working with not much UI experience here! I have engaged a front-end expert on our team to guide me so I won’t burden you w/ that :slight_smile: