Are you willing to submit a PR to fix? No
Requested priority: High
Products/sites affected:
The issue is happening only when you have a DetailsList that is set to unconstrained, has a lot of rows, and the width is greater than the space the DetailsList has.
When the user scrolls down, it 'resets' the sticky headers, and moves them back to position 0, even if the user has scrolled to the right.
Note that i think this was fixed for the horizontalConstrained DetailsList for #5169 so i'm not sure if the fix can be tweaked from there.
If the user has a lot of columns, and they begin to scroll down, after already scrolling to the right, the sticky headers reset back to the scroll left position 0. If the user were to scroll back to the top of the DetailsList , the sticky header positions would then shift back to the correct position.
Similar to the horizontal constrained DetailsList, the sticky headers should maintain position while scrolling horizontally when isScrollSynced is set to true on the sticky headers.
Please see the below code pen, which has the issue in question. An easy way to reproduce it though is to make the width of your browser smaller, just in case you have a massive screen.
https://codepen.io/sumboxcar182/pen/OwpKYx
Hi @sumboxcar182. I'm not able to repro this issue. If possible, can you provide a video demonstrating the issue? Thanks!
Hi @leddie24 ! Thank you for checking this out! I've recorded the issue and it's available here https://1drv.ms/v/s!Av-Zl403mjaL-s4JOftIAtpKODcyNg
I've also tweaked the codepen, and made it easier to see, as i had small column widths and i made them much larger to easily see it.
Also i realized my steps were horribly written previously so using that code pen the steps i took were:
1) Scroll down to the bottom of the DetailsList
2) Begin to horizontal scroll towards the right.
At this point you'll see the sticky headers are not moving while the scroll is happening.
If you scroll up afterwards, the headers pop back into place.
The given example is using an incorrect property name (constraintMode instead of the valid constrainMode property) and thus is not seen by the DetailsList component.
- constraintMode={0}
+ constrainMode={Fabric.ConstrainMode.unconstrained}
The component behaves as expected when adjusted to use the property name detailed in the documentation. Here is a fork of the provided example with the above change: https://codepen.io/josephdavis/pen/gZOGPp
This issue should be closed.
The given example is using an incorrect property name (
constraintModeinstead of the validconstrainModeproperty) and thus is not seen by theDetailsListcomponent.- constraintMode={0} + constrainMode={Fabric.ConstrainMode.unconstrained}The component behaves as expected when adjusted to use the property name detailed in the documentation. Here is a fork of the provided example with the above change: https://codepen.io/josephdavis/pen/gZOGPp
This issue should be closed.
Thank you for the solution @JosephDavis. @sumboxcar182 does the above work for you?
Hello!
Thank you @JosephDavis and @KevinTCoughlin for following up on this! I am completely embarrassed that there was a typo in that repo!
So i found that if i switched the fabric version back to 6.25.0 and then tried to replicate it with the typo fixed the defect would still happen. However on the latest version it is fixed and i think it might've came from pr #7060 so I'm going to close this out as i believe that fix will fix our issue as well.
I cannot thank you both for looking through this and helping out!