I am facing an issue in ios 11. When I open a header with multiple cells and closing it, the whole tableview shifts down. Any idea why its happening?

[reenaphilip]

[kgaidis]

@reenaphilip

I would need a lot more information to diagnose any issues.

Is it only iOS 11? It works in iOS 10?

Could you post a video?

Maybe any specific code that you think might be unusual too.

[reenaphilip]

@kgaidis
yes its working in ios 10. The issue is happening in ios 11.
I have separate headerview for the table. Maybe because of that its happening. The height of that header is fixed.
Attaching the video here.
IssueVideo.zip

[kgaidis]

@reenaphilip

Thank you for the video and explanation.

I can replicate the issue and it's not necessarily related to the header view. The problem seems to be an iOS bug - as you said, it doesn't happen on iOS 10.

When you expand a section, the table view content size increases. When you collapse a section, the table view content size decreases. UITableView has to sometimes scroll to adjust for these differences. To be more specific, when you scroll to the bottom and a section is open, and you are viewing a "content size area" that's LARGER than when the section is closed, the table view has to adjust the content offset. Seems like it adjust it wrong.

This will probably only happen in scenarios where the tableview is not too large and not too small.

Here is a possible temporary fix but its not perfect because there is a little bit of a lag on scrolling:

func tableView(_ tableView: FZAccordionTableView, didCloseSection section: Int, withHeader header: UITableViewHeaderFooterView?) {
        if tableView.contentOffset.y < 0 {
            tableView.setContentOffset(.zero, animated: false)
        }
    }

A more perfect solution would possibly be to listen to willCloseSection, and didCloseSection, and the contentOffset of UITableView. IF the UITableView.contentOffset.y is LESS than 0 WHILE the section is closing (willCloseSection got called, but didCloseSection did not yet get called), then we have encountered the bug, and we just set contentOffset.y to 0.

All these solutions are doable without messing with the interals of FZAccordionTableView.

I may or may not be able to get a fix in by the end of the week, but not guaranteed.

Note: Good test case is 19 sections, 7 rows.

[reenaphilip]

@kgaidis
Thank you so much for the complete explanation and temporary fix
I will try implementing this.

[kgaidis]

For anyone coming into this ticket with the same problem, I'd just use the fix below for now. It's not perfect, but it mostly gets the job done.

func tableView(_ tableView: FZAccordionTableView, didCloseSection section: Int, withHeader header: UITableViewHeaderFooterView?) {
        
        if (tableView.contentOffset.y < -tableView.contentInset.top) {
            tableView.contentOffset = CGPoint(x: tableView.contentOffset.x, y: -tableView.contentInset.top);
        }
    }

I tried overriding setContentInset but that did not get called for the bug-case (where content inset gets set to < 0). Most likely because it's adjusted internally using _contentOffset = X (setter not called). I have some ideas on how this could be fixed but they are hacky at best. As a result, I will just leave this fix here and it can be revisited later.