Fluentui: [DetailsList] Horizontal scroll appears with vertical one

[Basek]

Bug Report

• __Package version(s)__: 5.112.0
• __Browser and OS versions__: Google Chrome Version 66.0.3359.181 (Official Build) (64-bit)

Priorities and help requested (not applicable if asking question):

Are you willing to submit a PR to fix? No

Requested priority: Normal

Describe the issue:

Horizontal scroll appears with vertical one

Actual behavior:

Horizontal scroll appears with vertical

Expected behavior:

Horizontal scroll appears only when it is necessary

If applicable, please provide a codepen repro:

https://codepen.io/anon/pen/VdbmrZ

[natalieethell]

Hey @Basek thanks for submitting this issue! After a quick look, it seems to be similar to something we encountered with the Callout component's vertical scrollbar in the past. A solution included manually calculating overflow to determine if Popup (used by Callout) needs a scrollbar, otherwise setting overflow-y to undefined: https://github.com/OfficeDev/office-ui-fabric-react/blob/3ddbf34d984442f6302fad29d21d23d6512b6db1/packages/office-ui-fabric-react/src/components/Popup/Popup.tsx#L87

@aditima what do you think? Could we implement something similar to what we have for Popup's overflow-y, but for overflow-x in this scenario?

[Basek]

@natalieethell, I'm not sure about this. It seems to me that the problem is in column width calculation. There is viewport decorator which produce width for DetailsList, but it doesn't count vertical scroll width in a calculation and because of that horizontal scroll appears.

[natalieethell]

Hey @Basek you're right, the issue seems to stem from incorrect column width calculations. I'm proposing that we do our own width calculation to make sure that we are not counting the vertical scrollbar width and use that to determine whether we should manually set overflow-x to "scroll" or undefined.

Here are some findings I've collected from debugging:

Chrome and Edge seem to have different behaviors when calculating widths with vertical scrollbars, which may be why I'm able to repro this issue every time in Edge, but not every time in Chrome. Chrome appears to factor in or ignore the vertical scrollbar width, while Edge seems to consider the addition of a vertical scrollbar as overflow. In the inspector tool here, we can see that the focus zone element in Edge has a larger width than its parent, while they are the same width in Chrome.

Edge:

Parent 'div'

Focus zone element

Chrome:

Parent 'div'

Focus zone element

I'm going to look more into what this difference means for the width calculations in DetailsList and if manually calculating the width is an effective approach.

[micahgodbolt]

The provided pen appears to be working correctly. Can the author verify if this is still an issue? https://codepen.io/anon/pen/VdbmrZ

[agg23]

Still occurring in Firefox:

But not in Chrome. However, on load, Chrome initially has the horizontal scrollbar, then after half a second or so, it disappears.

Just for your reference, you have to scroll to the bottom of the DetailsList to see the horizontal scrollbar.

[micahgodbolt]

Oh I see, it's a different container that has the horizontal scrolling

Thanks for the update.

[dzearing]

@natalieethell will talk with @KevinTCoughlin

[KevinTCoughlin]

But not in Chrome. However, on load, Chrome initially has the horizontal scrollbar, then after half a second or so, it disappears.

Chrome likely doesn't exhibit this behavior because ResizeObserver is kicking-in after some delay, see https://github.com/OfficeDev/office-ui-fabric-react/issues/5280#issuecomment-431195520.

Will dig a bit more and see if I can understand the root cause for this particular issue better give the last week of profiling resize in DetailsList.

Edit: You can see this on the local test page for DetailsList in all browsers, http://localhost:4322/#/tests/detailslistbasicexample. However, in this _specific_ case the overflow-x and overflow-y are on the same container.

[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.