Cht-core: Rendering of cascading selects broken after 3.7.x

[derickl]

Describe the bug
We've supported cascading selects since v2.14. In a nutshell, cascading selects work by filtering child lists using values from a 'parent' list. Since v3.7, rendering of the child lists is broken - values appear empty. Surprisingly, the underlying markup contains the correct values to be rendered.

If we remove the choice-filtering, the child list renders correctly.

I've attached an example XLS form has been attached.

To Reproduce
Steps to reproduce the behavior:

1. Upload the attached XLS form and choose the 'Cascading' form from the action bar.
2. Select any option from the first list
3. The Second list will be pre-populated but with empty labels

Expected behavior
The child list should render with visible labels.

Logs
Nothing is logged in the browser console.

Screenshots

Environment

• Instance: (cmmb-ke.dev)
• Browser: (Firefox 73, Chrome 80)
• Client platform: (MacOS 10.15.3)
• App: (webapp)
• Version: (3.7.x, 3.8.x)

Additional context
This could be related to pre-generating the form HTML which was introduced in 3.7

Impact
We have a couple of projects that will be unblocked with fixing this. PIH's upgrade is blocked on this (228 users) and CMMB KE (120 users)

Example file:
cascade.xlsx

[garethbowen]

Consider including this in 3.8.1

[derickl]

@garethbowen we have training sessions next week and deployment thereafter. It would be great to have this fixed reasonably soon given there's currently no known workaround.

[dianabarsan]

@derickl I'm looking into this and it seems that your form is not rendering correctly because of an incorrect language tag.
After adding a default_language section in the settings tab and setting the value to en, the labels appear correctly.
Could you please try and confirm this could be a workaround?

[derickl]

@dianabarsan thanks for looking into this.

Confirmed this could be a workaround for the issue. Awesome find! cc @kitsao

[dianabarsan]

~I'm seeing the same behavior when rendering this form in 3.6.x but not on 3.5.x, so it's not related to serverside form generation.~

[dianabarsan]

It appears it has been, indeed, introduced in 3.7.x.

[dianabarsan]

Ready for AT on 6288-correct-form-language-for-dynamic-elements

[derickl]

LGTM @ngaruko

[garethbowen]

Merged to master and backported to 3.8.x