Selecting a row in a table causes the table to scroll to the top (which is bad). This is intermittent but bad behavior occurs 99% of the time; only occasionally does it work correctly.
In the video I carefully unpack every step associated with the execution of a select row handler and within the IDE we can see that nothing happening when the row handler executes causes the table to jump. Commenting out the row handler seems to "solve" the problem but restoring it and following through every step of the row handle shows nothing that explains the jumping behavior.
The bug seems to be inside the table component itself. The mere execution of the row handler alone triggers the undesirable scrolling.
Because selection of a row, and thus execution of the select row handler, is a side effect of displaying a Row Action menu, the mere display of a Row Action menu causes the table to jump and all visual context for the user is lost.
I had to turn OFF Height:Auto to eliminate undesirable fluttering in the table component and now I am faced with this problem. Row Action menus so broken they are unusable.
Ok. I found the problem. I would still say there is a bug in here. I found a workaround and then while writing up this report I found that the bug is no longer reproducible. In other words I removed my workaround just to confirm the failure mode, and the failure did not return.
So while I no longer can reproduce the behavior in the video I still think the following info may be useful to anyone working on the table component.
In this case two tables are inside a common container. It did not seem to matter if this container was set to auto height or not.
In order to stop a fluttering problem (documented in another post) I had long ago set the two tables to fixed, identical heights.
I had recently set the hidden property of the right table from a constant false to a formula that was true if there was no row selection in the left hand table.
Both tables get their data from a javascript variable which is an array of objects.
SO when the left hand table is refreshed the javascript variable that populates the right hand table is set to null.
Rather than distract the user with an empty table, I added a formula to the hidden property so the table would hide if it were empty.
When the selected row of the left hand table changes, a data set is recalculated and then .setValue is applied to the javascript variable that populates the right hand table.
A side effect of these actions is that the right hand table may transition from hidden to visible.
It is around these actions that the undesirable scrolling behavior in the left hand table (documented in the video) appeared. Anything that would cause the row selection handler for the left hand table to run would potentially hide or show the right hand table and what data it displayed.
When I removed the formula from the hidden property, and once again made it a constant false, the undesirable scrolling behavior in the left hand table stopped.
THEORY. The two tables share a parent container. The height of which could be a function of the tallest table. Yet messing with the autoheightness of the container did not seem to fix anything.
THEORY. When the right hand table is hidden it is no longer a factor in the height of the container. When the right hand table (re)appears the container might recalculate viewport/scrolling stuff.
THEORY. When the .setValue is applied to the javascript variable that populates the right hand table the height of right hand table could "pulse".
THEORY. If this "pulse" was a transition from data => empty state => (different) data THEN the function which calculates the hidden property of the right hand table might "pulse" as well. Or the height of the table may go from n => 0 => m. Even if n=m this sequence could still trigger "jitter" in the left hand table.
Anyway. As noted I "fixed" the problem by removing the expression to dynamically calculate the visibility of the right hand table. And this was my workaround which fixed all the problems you see in the video.
THEN while writing this follow-up I was able to add that expression back without breaking anything.
The order of events could matter. THEORY: the transition from hidden to visible COULD have an effect on sibling components inside a shared parent container. Components which become invisible and or zero height during the processing of changes to their data source could induce behavior in sibling components.
The exact sequencing and/or timing of these events could explain why I saw the problem, messed around with a lot of code, and then saw the problem inexplicably disappear. Since the table component is itself probably an aggregation of complex sub-components this problem where two tables share a parent container could be the "worst case scenario" for these sorts of effects.