`requireBorderCollapse` causes infinite updates

[jrmoynihan]

I just ran into a severe bug when using the requireBorderCollapse option. It appears that when enabled, one of the while loops in the component never ends, resulting in infinitely changing height to the CSS custom properties. This probably means than the calculation itself or exit condition is incorrect. I haven't walked through it yet to figure out exactly which line is the issue, however.

CleanShot.2023-11-07.at.10.52.12.2.mp4

Reproduction REPL:
https://svelte.dev/repl/d528940333b74791bb484e154a29eb76?version=4.2.2

[GenieTim]

Thank you for pointing this out.

As mentioned in the dev notes in the README, I had tried a lot of different ways to get this to work, and most attempts failed due to various reasons, including one, where – at least according to my understanding – truncation differences between JavaScript and CSS lead to infinite scrolling.

I am not exactly sure where your issue is coming from yet, but I anticipate a similar issue here: scrolling leads to an update to the css (to indicate the total scroll distance) leads to a change in scroll, leads to an update, and so on. This is a vicous cycle if the update to the CSS does not reflect the exact state we have at the point of no-further-scrolling. In other words, once we stop scrolling, whatever JavaScript decides is the new height of the height-changing tags, must not lead to anything triggering the onscroll event again.

Unfortunately, I currently do not have enough time to think back how all these computations worked and fix this. I see the following options:

1. You accept that for the end-user, things mostly work, and hope that I can fix things in the long term,
2. You are so kind to debug the issue yourself and submit a PR that I will gladly accept,
3. You find a way to do your CSS without requiring borderCollapse (or without leading to this issue, as seen e.g. in the example app),
4. You are patient enough to wait a few months until I fix things

Possible paths to a successful solution:

• find an issue in the computation, fix it
• find a different way, i.e., fix one of my other ideas mentioned in the dev notes,
• solve the symptoms rather than the problem: introduce a (configurable?) tolerance, under which the CSS is not adjusted.