Fluentui: DetailsList doesn't recalculate columns width correctly until resizing windows.

[dongnguyen9186]

Bug Report

• __Package version(s)__: 6.16.0
• __Browser and OS versions__: All browser

Priorities and help requested:

Are you willing to submit a PR to fix? (Maybe)

Requested priority: (Normal)

Describe the issue:

Try the example here: https://developer.microsoft.com/en-us/fabric#/components/detailslist
Scroll to example: 'Advanced DetailsList of 5000 items, variable row heights'
Resize window to smaller width then refresh page to see Item with long content is overlapped by vertical scrollbar until resize browser window.

Actual behavior:

Expected behavior:

WORKAROUND: Manually trigger the resize event then it work.

[micahgodbolt]

not sure if this is a quick fix or major re-architecture, but maybe something @KevinTCoughlin can take a peak at during shield this week. It's certainly come up a few times.

[KevinTCoughlin]

• Try the example here: https://developer.microsoft.com/en-us/fabric#/components/detailslist
• Scroll to example: 'Advanced DetailsList of 5000 items, variable row heights'
• Resize window to smaller width then refresh page to see Item with long content is overlapped by vertical scrollbar until resize browser window.

I can repro this issue by following the above steps in Firefox & Edge. Below is a screenshot of the behavior across Chrome, Edge, and Firefox on page reload.

In #5020, we added support for ResizeObserver which invokes _onAsyncResize the third time in Chrome. This invokes _adjustColumns in DetailsList which recalculates column positions with the scrollbar rendered. ResizeObserver is not yet available in Edge or Firefox (caniuse)

https://github.com/OfficeDev/office-ui-fabric-react/blob/c950c8723ad040a04cf17b224949ce98c61ebb67/packages/office-ui-fabric-react/src/utilities/decorators/withViewport.tsx#L55

To provide the desired behavior, DetailsList needs to invoke _adjustColumns once the vertical scrollbar has been rendered as it does when ResizeObserver is available. The solution should work cross-browser.

Forcing a recalculation of DetailsList columns

To demonstrate this, below is a diff that forces the third _adjustColumns using a setTimeout and a screengrab of the desired behavior:

diff --git a/packages/office-ui-fabric-react/src/utilities/decorators/withViewport.tsx b/packages/office-ui-fabric-react/src/utilities/decorators/withViewport.tsx
index 614c3a5fa..367366586 100644
--- a/packages/office-ui-fabric-react/src/utilities/decorators/withViewport.tsx
+++ b/packages/office-ui-fabric-react/src/utilities/decorators/withViewport.tsx
@@ -40,9 +40,7 @@ export function withViewport<TProps extends { viewport?: IViewport }, TState>(

     public componentDidMount(): void {
       const { skipViewportMeasures } = this.props as IWithViewportProps;
-      this._onAsyncResize = this._async.debounce(this._onAsyncResize, RESIZE_DELAY, {
-        leading: false
-      });
+      this._async.setTimeout(this._onAsyncResize, RESIZE_DELAY);

[KevinTCoughlin]

Tagging @billytrend who added ResizeObserver in #5020. @billytrend, any idea how we can provide a cross-browser solution for this problem so that DetailsList behavior is consistent across the browsers OUIFR supports?

[billytrend]

I couldn't find a good cross-browser solution when I made the change sorry. Googling shows a couple of polyfills but I'd imagine that it's a difficult feature to polyfill well.

[vishaldesai516]

Bug Report

• Package version(s): 6.16.0
• Browser and OS versions: All browser

Priorities and help requested:

Are you willing to submit a PR to fix? (Maybe)

Requested priority: (Normal)

Describe the issue:

Try the example here: https://developer.microsoft.com/en-us/fabric#/components/detailslist
Scroll to example: 'Advanced DetailsList of 5000 items, variable row heights'
Resize window to smaller width then refresh page to see Item with long content is overlapped by vertical scrollbar until resize browser window.

Actual behavior:

Expected behavior:

WORKAROUND: Manually trigger the resize event then it work.

Can you share how to implement the workaround?
Thank you .

[sumboxcar182]

Good morning and my apologies for the delay in getting back to you.

The workaround is a little hackish, but we are basically doing a

dispatchWindowEvent('resize');

Once the component mounts. It's not the best but it at least addresses the issue.

Thanks.

[vishaldesai516]

No worries.
Thank you for the response.
I am aware of this hack wanted to check if there are any other solutions.
But thanks a lot .

Regards,
Vishal

On Mon, May 6, 2019 at 6:25 AM Dan Greco [e-mail] wrote:

Good morning and my apologies for the delay in getting back to you.

The workaround is a little hackish, but we are basically doing a

dispatchWindowEvent('resize');

Once the component mounts. It's not the best but it at least addresses the
issue.

Thanks.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/OfficeDev/office-ui-fabric-react/issues/5280#issuecomment-489619108,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFKY5JVWL53GP27RAHJS7QDPUAWUHANCNFSM4FGGBEVA
.

>

*Vishal Desai *

[Pangamma]

Just want to say... resizing columns for DetailsList is a huge headache right now. Doesn't make any sense, doesn't work right. Whole thing is unusable. What the hell are these width units? Percentages? Inches? Probably inches!

[KevinTCoughlin]

Just want to say... resizing columns for DetailsList is a huge headache right now. Doesn't make any sense, doesn't work right. Whole thing is unusable. What the hell are these width units? Percentages? Inches? Probably inches!

They are absolute pixel values on resize, see:

@Pangamma, can you elaborate on what is unusable and does not work correctly?

Are you referring to the same issue reported above? If not, do you have an isolated repro of what you are experiencing?

[msft-github-bot]

Due to the complexity and dependencies of our List components, we are actively trying to minimize risk of regressions. We sincerely apologize that we won't be able to address this issue at this moment.