Issue upgrading to 3.2.0 from 3.1.9

[u01jmg3]

Since upgrading from 3.1.9 to 3.2.0 we are seeing an issue whereby the fixed header becomes stuck at the bottom of the DataTable when you scroll.

I see there is now a new floatingParent introduced in 3.2.0 - is this something we can opt out of using if it has issues?

For now we will have to stick to using 3.1.9.

[AllanJard]

Can you link to a test case so we can debug it please?

[u01jmg3]

It's going to be hard to extract my code in order to produce a test case. Might be easier if I isolate the exact commit from https://github.com/DataTables/FixedHeader/compare/3.1.9...3.2.0 that broke things for us.

Does any recent development ring a bell that might be causing this?

[AllanJard]

There were quite a lot of changes between the two, so I'm not sure how easy it will be to isolate it to a specific commit I'm afraid. There were also development bugs that were fixed in the process, so I suspect a test case with 3.2.0 is going to be the best way forward.

I don't see this issue with any of our examples so are you doing something with your table that our examples are not? Is it in a modal, or something else? It might be easier to build a new test case from the bottom up, rather than trying to strip back what you've got.

[u01jmg3]

Figured out the issue.

In v3.1.9 we were able to use:

fixedHeader: {
    header: true,
    headerOffset: $('.navbar-fixed-top').outerHeight().toFixed(1),
},

But now in v3.2.0 we must use:

fixedHeader: {
    header: true,
    headerOffset: parseFloat($('.navbar-fixed-top').outerHeight().toFixed(1)),
},

[AllanJard]

Interesting - what did $('.navbar-fixed-top').outerHeight().toFixed(1) resolve to in this case?

[u01jmg3]

A string: '116.7' - surrounded by single quotes

(Whereas $('.navbar-fixed-top').outerHeight() = 116.667)

[AllanJard]

Got it - thank you! Yes, we use headerOffset as part of a few numeric calculations, so it would have to be a number rather than a string. Our docs have it required as an integer, although any Javascript number would be fine.

I think since the docs do state that it should be an integer / number rather than a string, then this probably isn't something we would fix with a cast inside FixedHeader. That's the approach we've taken with other similar "overloads" for functions, since we'd just end up with loads of type checks in the code which would be 99% redundant.

[u01jmg3]

Thanks for confirming and I understand your reasoning.

I guess what threw us was that it used to accept a string but since v3.2.0 stopped doing so. Happy to adjust our code regardless.

[AllanJard]

Thank you for your understanding :)

[u01jmg3]

Correction: v3.1.9 did not accept a string as the headerOffset but the fact that we weren't passing in a number became more apparent with the move to v3.2.0. Either way, fixed now.