Foundation-sites: [Bug][6.6.2] Accordion height for pre "is-active" accordion item not correct

[D4rkiii]

Expected Behavior

In previous versions (<6.6.2) the accordion works as expected.
We have a nested accordion where the first level is always closed but the second level gets an "is-active" css class at the accordion-item (on page load) if the user has some filter previously activated. Before the upgrade to 6.6.2 if we open the first level accordion the second level was opened as expected but now the height and elements in the second level are broken.

6.6.2 with "is-active" on page load:

6.6.2 for all additional accordion items which has not set the is-active class on page load.

All versions before 6.6.2 shows our accordion correctly like the second case above. (Opened and correctly calculated height)
If i downgrade to 6.6.1 / 6.6.0 / 6.5.3 our accordion is working normal.

Current Behavior

The height is not correctly if the "is-active" class is set before the page is rendered.
The accordion looks broken.

Possible Solution

Currently i dont know how to fix it (expect to downgrade the version)

Test Case and/or Steps to Reproduce (for bugs)

Test Case: https://codepen.io/DarkStaRX/pen/VwvZBGx
I set the css class "is-active" above the headline "Test 1.1"
If you open the first accordion you will see height problems with the first (currently active) accordion. this just happens if you set the is-active class on the element by yourself. all other accordions working correctly.

How to reproduce:

1. Create a new accordion
2. Create a new nested accordion in the first one.
3. Set the active class on the first nested accordion.
4. Create a addition nested accordion below the active accordion
5. see the result ist broken for the active accordion

Context

Nested accordions to provide links for different categories. Working currently on production in a lower version of foundation.

Your Environment

• Foundation version(s) used: 6.6.2
• Browser(s) name and version(s): Chrome 80.0.3987.163
• Device, Operating System and version: Windows 10 1809 (OS Build 17763.973)
• Link to your project: Private Repository

Checklist

• [x] I have read and follow the CONTRIBUTING.md document.
• [x] This is a bug report or a feature request.
• [x] There are no other issues similar to this one.
• [x] The issue title and template are correctly filled.

[DanielRuf]

Hi @D4rkiii,

thanks for reporting this.

We will check this.

[DanielRuf]

Ok, I did a git bisect using git bisect start && git bisect bad v6.6.2 && git bisect good v6.6.1.

As I feares, a bugfix introduced this regression.

777baa81ede36d672b5369f9888e00f274c3ebc7 is the first bad commit
commit 777baa81ede36d672b5369f9888e00f274c3ebc7
Author: Daniel Ruf <[email protected]>
Date:   Mon Oct 14 23:39:44 2019 +0200

    fix: clear the animation queue - closes #10486

 js/foundation.accordion.js | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

[DanielRuf]

See https://github.com/foundation/foundation-sites/issues/10486

[DanielRuf]

It seems we need finish() here. I will create a PR to fix this.

[DanielRuf]

Would be great if you could test this too @D4rkiii.

I tested it locally and this fixes the old issue and this one.

[DanielRuf]

You should be able to verify this by also patching the latest release file manually.