Fluentui: Chrome: dismissing Focus-taking component resets page scroll to 0

[JoshuaKGoldberg]

Please provide a reproduction of the bug in a codepen:

I couldn't get this to repro in a codepen ☹ but it happens on Sway's React-ified site: https://sway.office.com/BpmCBa0Zt5EcbAbq?authoringPlay=true&publish

Bug Report

• __Package version(s)__: 6.30.0
• __Browser and OS versions__: Chrome 68, Windows 10

Priorities and help requested:

Are you willing to submit a PR to fix? Yes

Requested priority: High _(will become Blocking if not resolved in a couple of weeks)_

Products/sites affected: Sway _(specifically for Sways transformed to Word documents via Transform on word.office.com)_

Describe the issue:

When a Fabric component that uses focus is dismissed, page scroll is reset to 0. We've seen this with CalloutStore and Panel, though only CalloutStore is usable on the main site right now.

Actual behavior:

1. Open that URL
2. Scroll down in the page a bit
3. Click the top-right gear icon
4. Click back in the page
5. Observe that the page has been scrolled back to the top

Expected behavior:

On 4-5, the page should not reset scroll.

@micahgodbolt you mentioned you particularly enjoy browser-specific bugs, yes? 😁

[cliffkoh]

Thank you for the gif capture :) It is the first time we had a Chrome-exclusive bug ;) We have had ie11 only bugs, firefox bugs, safari bugs, but not Chrome (until now) or Edge only bugs yet.

[dzearing]

This is because when the menu is dismissed, we try and restore focus to the originating element... which in this case is the button, which rather than being position fixed is floated by the container. So restoring focus brings it back into "view" from its scroll perspective.

If you change this element highlighted below to position fixed, the issue goes away:

[dzearing]

I believe this is by design. I think there is even a prop on the menu to avoid this focus restoration behavior if you want to opt out.

[cliffkoh]

Closing this as by-design per the investigation from @dzearing. Please feel free to re-open if you deem it necessary :)

[JoshuaKGoldberg]

Hey @dzearing do you recall which menu prop it is?

This affects the Panel as well. Are you referring to something in IFocusTrapZoneProps?

[JoshuaKGoldberg]

If you change this element highlighted below to position fixed

That's not something we can do, unfortunately. That element isn't necessarily the only floating header visible on the page. We keep all of them in the .sway-stickyHeaderContainer div so that we can position them on top of each other with pure CSS.

I don't have permissions to re-open this issue. Could someone re-open it please?

[dzearing]

@JoshuaKGoldberg and I talked about this and walked through the problem.

The issue is that the container containing the button is position: sticky, (and in the initial investigation was using float to overlay.) When we move focus to the button (even if you ignore Fabric and just tab to a button in the container) the scroll position is reset.

This really seems like a Chrome bug, as moving focus to anything in the visible window shouldn't be moving scroll.

Closing the issue as we can't really work around this in Fabric.

[JoshuaKGoldberg]

Tracking issue in Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=810895&can=2&start=0&num=100&q=position%20sticky%20scroll&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort=

Edit: we should also note that changing the element to position: fixed makes the bug go away.

[JoshuaKGoldberg]

That is is resolved and this is fixed in the latest Chrome.

[KevinTCoughlin]

That is is resolved and this is fixed in the latest Chrome.

Awesome 👏, thanks for following up!